Woostack Harden

woostack-harden

An internal building block of woostack-build, also used by its project-backed Fix wrapper. Harden reconciles the user's local draft specification and, after delegated planning, its local direct-issue plan against bounded repository evidence. It asks before every material correction, records only what the user validates, and stops when no inconsistency remains. It owns no provider call, approval gate, planning, execution, review, Git mutation, or implementation.

Exact manifest admission

Build/Fix admits its baseline and supplies the permission-restricted run manifest defined by the shared artifact contract. For project-spec hardening, admit its local specification. For plan hardening, admit the complete local set of candidate direct issues, stable task keys, and dependency tuples; a parent plan issue is not a current plan record.

Verify run identity, owner-only permissions (0700 directory and 0600 regular file), monotonic revision, stable-key uniqueness, complete draft content, unresolved questions, and atomic compare-and-swap state. A missing, foreign, ambiguous, conflicting, partial, stale, overly permissive, symlinked, or malformed manifest blocks at the last verified boundary.

Harden performs zero provider reads and writes. It never creates a second project/plan, infers a native resource, or substitutes conversation history or repository evidence for the verified local manifest. The local run manifest is the canonical authority.

Reconciliation loop

Work one discrepancy at a time and ask one question per message. Begin with the exact manifest draft, then inspect only the bounded repository files, configuration, tests, documentation, and conventions that can bear on its decisions. Use the angle pre-flight to choose relevant reconciliation prompts; the canonical Review lenses remain authoritative.

At both specification and planning boundaries, Harden performs the removal-first check before accepting additive work: it verifies that the proposal removes, reuses, simplifies, or generalizes existing code before proposing additions. It challenges an additive draft when bounded evidence shows the same contract can be met by deletion or simplification, then asks the user to validate the safe removal—or the bounded reason addition remains necessary—without dropping behavior or safety requirements. least-code doctrine rather than duplicating it.

During specification reconciliation, Harden validates the Ideate-owned conditional ## Data models section against bounded repository evidence (existing schemas, migrations, route definitions, and data-layer conventions). If bounded evidence indicates table changes (entities/tables, fields/types, constraints, relationships, indexes, or migration/backfill) or API changes (method/path, authorization, request/response/error shapes, or compatibility), Harden verifies that the single ## Data models section is present and complete across all applicable categories. If the section is missing when table or API changes apply, omits applicable details, conflicts with repository conventions, or is present when neither applies, Harden treats that condition as a material discrepancy. Present the discrepancy and evidence to the user, ask for their decision, and wait for explicit validation. Harden never synthesizes or silently modifies the ## Data models section or any specification content from repository evidence.

For the first material inconsistency:

1. State the exact manifest field or stable task key and the bounded repository evidence, separating observation from interpretation.
2. Ask the user whether to correct the specification/plan, keep the current decision, or clarify the evidence. Offer a recommendation only as an explicitly unverified recommendation.
3. Wait for explicit user validation. Never silently change a specification or plan from repository evidence, even when the repository convention appears unambiguous or safer.
4. After a correction is validated, atomically replace the affected manifest draft content and unresolved-question state, preserving unrelated user-authored content, before asking the next question.
5. For plan changes, verify the affected stable task mappings (canonical issue references for retained tasks and explicit null entries for new tasks) and complete local dependency set; never simulate dependencies in prose, infer issue endpoints, or infer parent absence.

A user choice to keep an inconsistency is itself a decision, not permission to rewrite it. Record a rationale only when the user explicitly asks for that material to be part of the specification or plan. Repository evidence can expose a question; it cannot answer one.

Completion and single handoff

Continue until the bounded inspection finds no remaining material inconsistency, every recorded correction agrees with explicit user validation, the conditional ## Data models section is validated (present with all applicable details when table or API changes apply, or omitted when neither applies), and the unresolved-question set is empty. Then verify the complete manifest once more:

• for a project specification, return the baseline project identity/revision, local specification, and run/process/manifest identity;
• for a plan, return the baseline project identity/revision, sorted stable task mappings (canonical issue references for retained tasks and explicit null entries for new tasks), exact local dependency set, and run/process/manifest identity.

Hand this one local result back to the owning Build/Fix wrapper. This is not approval and does not transition phases. The wrapper writes project-spec.md or execution-plan.md directly under the run directory, handles optional mirror synchronization and retention, and owns the Stop here/Execute/Abandon handoff. Harden invokes none of those activities and never edits implementation source.