[godv61]

Problem and behavior

Implementation could proceed before the user had approved an unambiguous scope. This release requires clarification, a generated requirement summary, and human approval of that exact document version before implementation. Tool execution approval cannot substitute for business approval.

• Apply the confirmation contract to all four complexity grades; low complexity uses a short summary in its initial stage.
• Invalidate implementation access when requirement fields or the approved document change. Reuse valid confirmation, and synchronize tool visibility and execution checks after exact document restoration.
• Show the document, version, feedback, and confirmation state in the ledger, with strict browser codecs.
• Require explicit delivery intent and complexity when creating tasks. Older records remain readable but cannot execute under the new contract; history cannot authorize a new commit.

Validation

• Type checks and server/browser/hook builds pass.
• 396 regression tests: 389 pass, zero failures, seven skips for an absent historical host seeder package; P0 adds 143 assertions.
• Real DSH 0.2.1-rc.3 keyless host probe covers question transport, native tool guards, confirmation reuse, invalidation/restoration, and read-only records, with zero model calls.
• DSH contract check covers 40 Remote methods and 79 strict codec factories. Isolated package checks cover shipped entry points, core regressions, real Git hooks, and the CLI.

Upgrade and scope

Breaking workflow change: task creation requires explicit intent and complexity. Active records missing the current confirmation contract cannot resume execution. This is a generic, language-independent change; no project data migration is performed.

Custom Skill multi-document outputs and multiple approval roles are deferred. Automated contract checks do not replace real-model business acceptance or manual UI testing.