Section 8
Read dependencies and resolve cycles
A dependency is a specific relationship supported by source evidence. Begin with the declared coordination mode and the graph objective. Build-order, runtime calls, information flow, deployment, and knowledge relationships are different semantics. A graph can be correct for one and misleading for another. Record the objective before treating arrows as ordering instructions. Cycle-driven resolution §§1–3 · Setup contract
The local dependency records remain authoritative under K-DEP-1. Project DAGs and closure snapshots are approved or derived views for stated purposes; they do not create a second central dependency database. Inspect the selected project snapshot through its live pointer and verify its source basis. A newly opened session does not warrant rebuilding a still-current accepted DAG. Re-derivation is event-driven by decomposition revision or scope change under the doctrine and the project's adopted triggers. CONTRACT K-DEP-1 · Cycle-driven resolution §4
dependency-extract works locally in two passes: definition anchors to existing tree/requirement identities, then execution relationships. It produces Dependencies.csv and _DEPENDENCIES.md; it does not restructure decomposition or build the whole project graph. Preserve evidence location, stable row identity, direction, explicitness, confidence, extraction history, and fulfillment state. Unresolved targets remain UNKNOWN or TBD; do not manufacture a deliverable to make an edge resolve. Dependency extraction
In the v3.1 register, ANCHOR rows retain definition and requirement traceability; EXECUTION rows carry production relationships. Direction is relative to the register owner: UPSTREAM means it needs a contribution from the target; DOWNSTREAM means it supplies a contribution to the target. FirstSeen, LastSeen, and extraction Status describe source presence; RequiredMaturity, ProposedMaturity, and SatisfactionStatus describe the required condition, proposal, and fulfillment. Preserve declared rows and matched identities; retire unseen extracted rows rather than deleting them. Non-gating graph candidates do not use Status=CANDIDATE. Extraction leaves source documents, decomposition, and _REFERENCES.md read-only. Dependency extraction
Read extraction status separately from satisfaction. ACTIVE means a relationship is currently observed; it does not mean fulfilled. RETIRED preserves a formerly extracted relationship; it is not a lifecycle state. SatisfactionStatus records whether the input remains pending, is in progress, is satisfied, or has another permitted disposition. An IN_PROGRESS dependency field is a different vocabulary from a deliverable's IN_PROGRESS lifecycle. Normalize legacy labels only under authorized writes and preserve their origin. Dependency extraction · SPEC §3.4
Readiness follows the project's actual rule. Revised App selection verifies required inputs at consumption from dependency records and owning contracts; a historical Remaining item's Depends line is not an additional prerequisite for recognizing a real dependency. PEC retains its earlier conjunction involving an active PREREQUISITE, an unsatisfied status and the selected item's Depends line. Other relationship types do not become blanket whole-deliverable blockers, but their actual obligations still apply. No topology calculation bypasses a named owner gate or reliance hold. App selection rules · PEC loop §5
A strongly connected component, or SCC, identifies a set with circular ordering under the selected semantics. Its condensation is acyclic, but collapsing the picture does not settle the underlying production decision. Unresolved cycle-participating edges stay non-gating: they cannot drive dispatch readiness, blocker queues, wave placement, schedules, or implementation-readiness claims. Keep independent work available from a verified basis. Cycle-driven resolution §2
The doctrine names four moves. Decompose separates an overly broad node, often an interface from implementation. Invert places dependence behind a contract. Merge treats the coupled work as one indivisible unit. Cut reclassifies an edge as outside the graph's objective. Record the rationale for every remedy. Decompose and invert are design refinements agents may propose; cut and merge encode interpretive authority and are human-gated. Use a short note for an obvious bounded refinement and a decision packet for contested or objective-dependent choices. Cycle-driven resolution §§2–3
An acyclic graph is not proof of a complete or useful graph. Verify inventory coverage, missing targets, edge meanings, and relevant external inputs before drawing a readiness conclusion. An omitted dependency can make the topology look cleaner while making execution less reliable. A large SCC should direct attention to decomposition and meaning; it is not a reason for a tool to auto-cut relationships until the drawing passes. Cycle-driven resolution · Dependency extraction
audit-dep-closure freezes an independent scope inventory and the graph filters before analysis. Its default topology uses active EXECUTION relationships targeting Deliverables; other target types remain relevant to the wider dependency account. Missing or invalid registers remain in the coverage denominator. The read-only examination returns a new immutable snapshot with input and tool identities, effective settings, findings, limitations, and a rerun method. scc-resolution-case can organize a bounded case under an existing PKG-00 control deliverable. That method writes case evidence, while the owning workflows amend product contracts, decomposition, and dependency registers. Case closure needs a cited subsequent DepClosure result. Neither method creates the missing project structure or grants a graph amendment. Dependency closure contract · SCC resolution case