Design Plan Convergence

Design and Plan Convergence Audit

Core contract

Audit one current readiness gate from current evidence. Keep the audit read-only. Treat old reports and modifier summaries as claims, never as facts.

1. Read applicable organization, project, methodology, repository, and artifact-format rules.
2. Freeze the charter, gate, artifact set, Non-Goals, decisions, accepted risks, evidence boundary, and snapshot.
3. Use the smallest evidence set that proves or disproves the gate, including complete affected decision chains and siblings.
4. Do not edit artifacts, implement future work, run release verification, or broaden the charter.
5. Route only BLOCKER and REQUIRED findings to remediation.

Choose one audit mode:

• Audit: inspect the current artifact without relying on an earlier verdict.
• Re-audit: verify claimed repairs on the current snapshot.
• Convergence: detect recurrence, drift, and repair-created mechanisms.

Select the gate and risk profile

Use the explicit gate, otherwise infer it from the primary artifact:

Do not automatically advance from document convergence to implementation or release. A missing plan at DESIGN is NEXT STAGE NOT STARTED, not a blocker.

Use AUTO unless the user selects LEAN or ASSURANCE:

• LEAN: cover the main flow, approved boundaries, credible single failures, and mandatory safety/data protections.
• AUTO: apply LEAN globally and a local ASSURANCE SLICE only to security/trust boundaries, money/quota, irreversible data changes, public compatibility, concurrency/idempotency/state machines, or production activation/rollback.
• ASSURANCE: deepen evidence for the selected gate; never change the gate or authorize implementation.

If assurance would add a capability, controller, persistent state, protocol, artifact, live-environment execution, or Non-Goal change, return DECISION REQUIRED. Read references/gate-risk-watch-contract.md for classification, risk slices, test admission, and stopping rules.

For an implementation plan or plan-only request, read references/implementation-plan-profiles.md. For design artifacts that are not OpenSpec, read references/generic-design-profile.md. For design or plan artifacts whose frozen scope authoritatively includes user-visible UI/UX behavior, read references/ui-ux-planning-profile.md. Do not select this profile from frontend technology or UI-related keywords alone. For independent closure, re-audit, or multi-cycle work, read references/evidence-isolation-snapshots.md.

Freeze the boundary

Record:

gate, mode, and LEAN/AUTO/ASSURANCE profile
charter, observable result, scope, Non-Goals, must-not-change behavior
primary artifacts and artifact generation
editable artifacts: none
read-only rules, code, configuration, tests, runtime, and external evidence
acceptance environment and gate completion criteria
frozen decisions, unresolved decisions, accepted residual risks
snapshot and boundary version

“Full boundary” means the frozen charter, applicable rules, and complete impact chains, not the whole repository. Verify current facts from code, configuration, tests, CI, or runtime evidence; do not infer them from target documents.

Run the OpenSpec preflight

For an artifact set governed by OpenSpec delta semantics, run this mechanical preflight before the general gate lenses:

1. Resolve the current change, authoritative OpenSpec root, governing format, and snapshot. For a standard repo-local change, run the read-only validator: openspec validate <change> --type change --strict --no-interactive. If governing rules or a selected store require another exact command, use that command instead.
2. Parse delta operation and Requirement headings. For every MODIFIED or REMOVED Requirement, locate its Requirement heading in the authoritative main spec using OpenSpec's canonical normalized-header matching. An intended rename requires the format-native rename mapping. Do not substitute an unanchored body search or stricter byte-for-byte matching.
3. When a delta capability has no authoritative main spec, treat it as a new capability and confirm that it uses the governing added-requirements operation header; under the standard format this is ## ADDED Requirements.

Any unsuccessful mandatory validator or preflight check is at least REQUIRED and prevents READY; upgrade it to BLOCKER only when the normal finding contract requires that severity. Continue every lens whose evidence remains reliably readable. If a structural failure makes an artifact identity or boundary unreliable, mark only the affected partition UNVERIFIED, retain the corresponding finding at its classified severity, and state why.

Apply this bounded textual trace only when the delta contains MODIFIED or REMOVED Requirements from an existing main spec:

1. For each decision in the frozen change, search separately for its stable identifier and exact heading or title, where present. Use the union of fixed-string matches; do not derive extra search terms from prose.
2. Treat matching Requirements as the affected candidate set and review only that set for semantic contradictions with the decision.
3. If the search has no match, report only that the bounded textual trace found no explicit link. Do not claim that no impact exists.

Pure ADDED new-capability deltas and bug fixes with no spec change skip this OpenSpec-specific textual trace, but never skip otherwise applicable gate lenses. Do not extend this adapter into inferred shared-semantic-resource or unmentioned-Requirement analysis. This limit scopes only the adapter's candidate generation; it does not suppress conflicts directly evidenced while applying the general lenses.

Apply the gate lenses

At DESIGN READY, audit:

1. Premise/value: problem evidence, observable result, completion criteria.
2. Scope/boundary: scope, Non-Goals, must-not-change behavior, no hidden product expansion.
3. Architecture/contracts: one owner per behavior, decision trade-offs, compatibility, affected consumers, intermediate states.
4. Delivery/operations: dependencies, implementation ownership, rollout, backup/rollback or fail-closed principle, accepted residual risk, and automation proportional to repeat risk.

At PLAN READY, audit the plan against frozen upstream design through:

1. Dependency: outputs exist before use; environments, owners, and permissions are ordered.
2. Granularity: tasks split by behavioral result, compatibility phase, or failure boundary, not file or line count.
3. Risk: critical sequencing, destructive actions, compatibility, rollback, and current-gate assurance slices are explicit.
4. Coverage: every approved contract maps to work and verification; every task maps back to an approved contract.
5. Feasibility: current paths, symbols, interfaces, tools, cwd, prerequisites, commands, and oracles are credible.

Do not import a global “cover every edge case” objective. Apply the bounded UI/UX planning profile only when its authoritative-scope trigger holds. Other optional DX, security, or operations lenses apply only when the frozen scope contains them. Automate checks that are repeated, high-risk, cross-service, or prone to false positives; do not add a script merely to make a one-time low-risk review look complete.

Complete the frozen lens and risk-partition inventory before issuing the first repair handoff. Time spent is not coverage. Stop an over-deep branch by applying the risk, sufficiency, and routing contracts; do not stop the whole audit while mandatory partitions remain incomplete.

Close decision chains

Trace each relevant path:

evidence -> requirement/scenario -> decision/trade-off -> implementation owner
         -> valid and rejected behavior -> verification responsibility
         -> rollout/acceptance -> rollback/recovery principle

Preserve artifact ownership:

• proposal: problem, value, scope, Non-Goals;
• spec: observable behavior and acceptance boundary;
• design: decisions, trade-offs, flows, compatibility, risks;
• tasks: implementation and verification responsibility;
• plan: order, paths, interfaces, commands, oracles, phase boundaries.

These are semantic roles, not required filenames. A generic document may own several roles; audit its content rather than forcing it into an OpenSpec shape.

Use stable Requirement, Scenario, Decision, and Task identifiers where the artifact format supports them. A downstream artifact must not silently rewrite an upstream decision.

Keep tests at the correct stage

• OpenSpec defines testable behavior, critical journeys, acceptance scenarios, and verification ownership; it does not need an exhaustive test-case library.
• A plan maps contracts to unit, integration, E2E, or release responsibility, prerequisites, environment, fixture category, and oracle; it does not implement the tests.
• Development creates detailed cases and fixtures.
• Integration and release workflows execute full E2E, smoke, deployment, rollback, and recovery checks.

At DESIGN and PLAN, future outcomes remain PLANNED. Do not fail an earlier gate because later tests have not run. Require only gate-appropriate evidence:

Use static contract audit, gate-appropriate safe rehearsal, and reverse traceability. At DESIGN/PLAN, rehearsal validates current facts and feasibility; it does not execute future implementation. Select adapters from artifact identity and governing rules, not installed CLI availability. Never install validators automatically or run one that writes, uses the network, or changes the environment without authorization. After one safe unavailable or unauthorized check, mark the evidence UNVERIFIED.

For an exact mandatory validator or action, equivalent evidence cannot substitute; retain REQUIRED until it succeeds on the current snapshot or the requirement is waived or amended. For a mandatory property or evidence outcome, equivalent current evidence may satisfy its parent contract; otherwise retain REQUIRED. Optional-validator unavailability alone creates no finding; continue the semantic audit. Missing execution authorization alone does not create DECISION REQUIRED. Route future-gate execution as NEXT-STAGE NOTE.

Manage findings

Use project statuses when stricter. Otherwise:

• BLOCKER: the main flow cannot work, contracts conflict, or reachable security/data/irreversible harm lacks a safe decision.
• REQUIRED: necessary for the current gate or a proportionate prevention of major quality failure.
• CONCERN: confirmed non-blocking residual risk requiring authorized acceptance.
• WATCH: low-probability trigger-based observation; do not remediate now.
• NEXT-STAGE NOTE: work owned by development, integration, implementation verification, or release.
• OUT OF SCOPE: real, separately deliverable work outside the charter.
• REJECTED: disproved claim.
• CLOSED: independently verified root-cause closure.

For each BLOCKER or REQUIRED, record the violated current-gate contract, evidence, root cause, siblings, minimum correction invariant, authorized boundary, and closure evidence. A modifier may return a remediation-defined candidate outcome, but never CLOSED or READY.

Read references/templates.md only when a formal ledger, manifest, attestation, or report is required.

Audit frequency and verdict

• Perform one initial full-boundary audit.
• If it finds no BLOCKER or REQUIRED and the snapshot stays unchanged, it is also the final audit; do not repeat it.
• After mutation, inspect the exact diff plus the complete affected decision chain, siblings, removed semantics, and new mechanisms.
• Upgrade an intermediate review to full after a gate, boundary, rule, profile, generation, or key mechanism changes.
• In a standalone re-audit, perform one blind full audit on the stable repaired snapshot. Under design-plan-convergence-loop, follow its frozen cadence: one final blind discovery per artifact generation, then mandatory closed-world certification. Reuse a complete zero-blocking blind synthesis only on its unchanged snapshot; after post-blind root-preserving repairs or another escalation trigger, run a fresh whole-artifact consistency scan. Do not interpret a certification repair as a reason to restart blind discovery.

Declare READY only when:

1. current-gate BLOCKER = 0 and REQUIRED = 0;
2. no unresolved decision or upstream reopen affects the gate;
3. current evidence is reproducible and future checks have stable planned oracles;
4. concerns are authorized and watch/next-stage items are correctly routed;
5. no unapproved scope change or repair-created subsystem remains; and
6. the audited snapshot is unchanged.

Lead with the terminal defined by the selected gate profile. Use <GATE> READY, <GATE> NOT READY, or DECISION REQUIRED only when the profile does not define a more specific routed terminal. Report blockers and required findings first, then accepted residuals, routed items, verified closures, and the next action.