DQ01 — Resolved. See decision 0007 and decision 0014. Identity is a hash of a version's source with nothing excluded, and a revision states its own parent, so re-submitting the same content yields the same identity and therefore one version. A retry whose rationale was reworded is closed separately, by refusing a revision that changes no Step and no goal. No caller-supplied key exists, because an asserted value can be supplied wrongly and the consequence would be permanent.
DQ02 — What form do progress records take? Decision 0014 settles versions: a version is the authored module, stored unchanged, and identity is the hash of those bytes rather than of any rendering. It says nothing about progress records, which are operational, written by Compass rather than by hand, and must stay inert — nothing in the progress layer is evaluated, because reading progress must not become another place foreign code runs.
Unresolved: what a progress record is serialized as, and how its identity is computed given it is not a module and has no source bytes an author chose.
DQ03 — What vocabulary expresses acceptance? Decision 0006 establishes that acceptance is machine-checkable, which rules out prose. Decision 0013 settles that the vocabulary is not declared: Compass fixes the structure of a Plan and nothing about the words inside a criterion, and the defect that would otherwise be silent is caught by cross-checking a record against the criteria it could contribute to when it is written.
What remains open is the predicate language itself: how evidence is named and matched, whether predicates compose, and whether one may reference another Step.
Constrained by CMP.DM-R15: readiness must explain itself, so a predicate that cannot report why it failed is unusable regardless of expressive power. This is the largest open question in the model, and the contract is incomplete without it.
DQ04 — Resolved. See
decision 0017. A Plan's
identity is the content hash of its origin (parent-less) version — derived,
never declared or minted, encoding no location. Two versions are the same Plan
when they share an origin, and the origin's own identity is the PlanId. Human
readability is carried by the required goal, not by the identity, so the
identity need not be readable and is fully derived.
DQ05 — What is a Plan scoped to? The catalog is a single tree replicating across machines. Unresolved: whether a Plan declares an owning workspace, whether agents filter by host as the agent catalog does, and what "my plans" means for a Plan that outlives the worktree it began in.
DQ06 — Resolved. See decision 0015. Reading is served from an index keyed by version content hash. It is required rather than optional, because reading evaluates and a question spanning many Plans is many evaluations. It holds no authority, is machine-local, and is never replicated, so it can be deleted at any moment with nothing lost. Compaction remains a separate problem: the index makes re-reading cheap and does nothing about how many files exist.
DQ07 — Is a version's author observed or claimed?
A version is stored exactly as authored, so Compass cannot stamp it: whoever
writes the module writes the author field, and nothing checks it against the
identity Compass observed. Decision 0008 draws precisely this distinction for
evidence — a recorded actor can be trusted, a claimed attribute cannot — and
version authorship sits on the claimed side, while decision 0002 Amendment 3
justified recording an author on the grounds that reconciling divergence starts
with who wrote each side.
Unresolved: whether Compass refuses to commit a module whose stated author differs from the acting identity, whether it records the observed identity separately from the claimed one, or whether authorship is simply a claim like any other and is documented as such. Progress records are unaffected — Compass writes those, so their actor is observed.
DQ08 — Resolved. A reconciliation carries forward every Step of every
parent, so nothing can be lost by choosing a side. Where two parents
define the same Step with different content, the reconciliation must state the
surviving intent with an explicit edit for that Step, and is refused
otherwise — naming the Step and both differing sides. A Step only one side
carries, or that both sides left identical, is not a conflict and is carried
forward unchanged.
This takes the first of the two candidates, and for the reason the second was suspect: silently keeping one side and dropping the other would let a reconciliation assert intent nobody wrote, which is the exact failure the whole divergence model exists to avoid. Refusal is consistent with divergence resolving by authorship — the surviving intent is authored, never inferred. DQ09 — What are the evaluation bounds, and who sets them? Decision 0014 requires that evaluation be bounded in time and memory and that exceeding a bound be reported. It does not say what the bounds are.
Unresolved, and awkward in both directions: a fixed bound is a value nobody can tune for a large Plan, and a configurable one is a value an operator can set wrongly — including wide enough to remove the protection — which is exactly what CMP-R10 warns about. Whether a bound may differ between machines is the sharper form of the question, since a Plan readable on one machine and stopped on another is a Plan two machines disagree about.
DQ10 — How does a version record the API it was authored against? The authoring library changes, and a committed version is immutable and read forever, so a version must be evaluable under the API it was written against rather than whichever is current. The compatibility identity is settled (06-api); how a version carries it is not. Candidates: a field in the plan call, an import specifier that encodes the version so the reference is itself the pin, or a manifest beside the catalog. The import-encodes- it option is attractive because it makes the pin a resolved reference rather than an asserted value, consistent with CMP-R10, but it entangles the library's distribution with the catalog's contents.
DQ11 — Can a Step depend on a Step in another Plan?
A cross-plan reference (importing another Plan's version) resolves and is
checkable. A cross-plan dependency edge — a Step whose dependsOn names a Step
in another Plan — does not work: a dependency is validated against the importing
version's own Steps, and readiness folds within one Plan. Making the edge real
raises questions neither mechanism answers: does the other Plan's Step being
accepted block this one; how does readiness fold across Plans; what does an
out-of-Plan retirement do to a dependent here; and what happens when the other
Plan diverges. Until those are settled the reference is supported and the edge is
not.
DQ12 — Does authored content carry variable references, or only the root?
CMP.FS-R05 promises machine-agnostic paths via variable references inside
authored content. In practice a version references its parents by relative
import and the catalog root is environment-resolved, which achieves
machine-agnosticism without any variable expansion in the module resolver. Either
the requirement is satisfied by that weaker mechanism and should say so, or
variable-in-content is a real feature still to build. The relative-import form is
also what makes the flat per-Plan versions/ layout load-bearing (a parent
is named by relative path), so this interacts with how a catalog may be
reorganized.