Add verification override mechanism reference

[davesienkowski]

Pre-submission checklist

• I have confirmed this improves existing behavior -- it does not add a new command, workflow, or concept
• I have searched existing issues and this enhancement has not already been proposed
• I have read CONTRIBUTING.md and understand I must wait for approved-enhancement before writing any code
• I can clearly describe the concrete benefit -- not just "it would be nicer"

What existing feature or behavior does this improve?

The verification behavior of agents/gsd-verifier.md when a must-have item intentionally deviates from the plan.

Current behavior

The gsd-verifier checks each must-have item from the plan and marks it as PASS or FAIL. There is no mechanism to accept an intentional deviation -- for example, when the plan specifies unit tests for an auth module but the implementation uses integration tests with an external OAuth provider instead. The verifier repeatedly flags this as a failure, and the developer must either change the implementation to match the plan or manually edit VERIFICATION.md to mark it as passed. Neither option is correct -- the implementation is intentionally different for a good reason.

Proposed behavior

A new reference document get-shit-done/references/verification-overrides.md defining an override mechanism:

Override format in VERIFICATION.md frontmatter:

overrides:
  - must_have: "Unit tests for auth module"
    reason: "Auth uses external OAuth provider, tested via integration tests"
    accepted_by: "user"
    accepted_at: "2026-02-12T10:00:00Z"

How overrides work:

1. Verifier checks each must-have item
2. Before marking as FAIL, checks if an override exists for that item
3. If override found: marks as PASSED (override) with the reason
4. Overrides persist across verification cycles

The verifier agent references this document to handle overrides during verification.

Reason and benefit

Why the current behavior is a problem:
Real-world development involves trade-offs. A plan may specify one approach, but during implementation a better alternative is discovered. Without an override mechanism, the developer is forced to either implement the suboptimal approach (to pass verification) or manually hack VERIFICATION.md (losing the audit trail). Both outcomes are worse than an explicit override with a documented reason.

Concrete benefit:
Developers can accept intentional deviations with a documented justification. The verifier stops flagging known-good deviations. The override audit trail preserves the reasoning for future reference.

Scope of changes

Files created:

• get-shit-done/references/verification-overrides.md -- override format, behavior, and management guide

Files modified:

• agents/gsd-verifier.md -- add reference to verification-overrides.md, add override checking logic before FAIL

No new dependencies.

Breaking changes

None. Additive enhancement. Existing VERIFICATION.md files without overrides behave identically.

Alternatives considered

1. Edit VERIFICATION.md directly to mark items as passed -- Loses the distinction between "verified correct" and "intentionally different." An override preserves both the deviation and its justification.
2. Skip verification for phases with known deviations -- Too coarse. Overrides are per-item, not per-phase. Other must-haves in the same phase should still be verified.

Area affected

Core workflow (init, plan, build, verify)

[trek-e]

✅ Approved as enhancement.

Solves a real friction point. The override format with reason + accepted_by + timestamp preserves the audit trail properly.

Implementation notes:

• Override matching should be fuzzy (not exact string match) — must-have wording may differ slightly between PLAN.md and VERIFICATION.md
• PASSED (override) should be visually distinct in verification output so it's clear which items were overridden vs genuinely verified
• Consider whether the verifier should prompt the user to create an override when a FAIL looks like an intentional deviation, rather than requiring manual frontmatter editing

@davesienkowski — labeled approved-enhancement. You're clear to implement.