TenantAtlas/specs/439-branch-topology-local-evidence-truth/checklists/requirements.md

Requirements Quality Checklist: Spec 439 - Branch Topology and Local Evidence Truth

Purpose: Validate that the corrected Spec 439 requirements are complete, unambiguous, repo-grounded, proportional, internally consistent, and ready for a separate implementation loop. This checklist tests requirements quality, not implementation. Created: 2026-07-10 Corrected: 2026-07-11 Feature: spec.md Snapshot boundary: This checklist records the requirements-preparation close-out before implementation began. Current implementation/task/evidence state is owned by tasks.md and, after Phase 8, implementation-report.md; the historical statements below are not live implementation status.

Candidate and Repository Truth

• CHK001 Is the candidate identified as directly user-provided and bounded to current repository-governance/evidence defects? [Completeness, Spec §Preparation Selection Summary]
• CHK002 Are the wrong-base, false-report-success, JUnit-validity, and blocking-budget defects named at current repo call paths without claiming implementation? [Traceability, Spec §Context and Problem Statement; Plan §Correction Preflight Evidence]
• CHK003 Are Spec 437 and Spec 438 classified as read-only context with an explicit unchanged requirement? [Consistency, Spec §Preparation Selection Summary; FR-052]
• CHK004 Does the Candidate Check contain the mandatory problem, failure, improvement, smallest version, complexity, why-now, why-not-local, class, red flags, defense, score, and decision fields? [Completeness, Spec §Spec Candidate Check]
• CHK005 Is the 11/12 score arithmetically correct and supported by current workflow/evidence value rather than future flexibility? [Measurability, Spec §Spec Candidate Check]
• CHK006 Are candidate approval, requirements readiness, and implementation completion kept as three separate claims? [Clarity, Spec §Candidate and Readiness Decision; §Final Spec Gate]

Constitution Amendment Authorization and Scope

• CHK007 Does the spec explicitly authorize the narrow Constitution branch-topology amendment as its first mutating implementation step? [Completeness, Spec §Constitution Amendment Authorization; FR-001]
• CHK008 Is the governance basis documented: explicit Constitution update PR, rationale, impacted artifacts, SemVer decision, and Last Amended, with no mandatory separate preceding feature spec? [Traceability, Spec §Governance basis; FR-002, FR-007]
• CHK009 Does the amendment scope define exactly the three branch roles, scope-specific routing, explicit cross-stream/promotion classification, and no wrong-family/HEAD~1 fallback? [Completeness, Spec §Authorized amendment scope; FR-003]
• CHK010 Are general Constitution reduction, UI/UX cleanup, skill reorganization, architecture/security cleanup, and unrelated principles explicitly excluded? [Scope, Spec §Forbidden amendment scope; FR-004]
• CHK011 Does the spec distinguish authorization of the future amendment from falsely claiming that the Constitution is already amended? [Clarity, Spec §Governance basis]
• CHK012 Is SemVer left for an explicit policy-based Phase 1 decision, with PATCH not silently predetermined? [Clarity, Plan §SemVer handling; FR-002]
• CHK013 Are the required amendment metadata and unchanged Ratified-date expectation measurable in Phase 1 evidence? [Measurability, Plan §Phase 1; Tasks T003-T006]
• CHK014 Is the same-feature-PR posture clear without weakening the rule that dependent work waits for amendment validation? [Consistency, Spec §Candidate and Readiness Decision; FR-005, FR-007]

Mandatory Phase and Gate Quality

• CHK015 Are Phases 0 through 8 named in the required order in both spec and plan? [Consistency, Spec §Mandatory Implementation Phases; Plan §Mandatory Implementation Phases]
• CHK016 Is Phase 0 explicitly read-only and the only work permitted before the first mutation? [Clarity, Spec §Mandatory gate sequence; Plan §Phase 0]
• CHK017 Is Phase 1 the narrow Constitution amendment rather than an external prerequisite? [Consistency, Spec §Phase 1; Plan §Phase 1; Tasks Phase 1]
• CHK018 Does T006 form a global hard gate that blocks every Phase 2-8 task? [Measurability, Tasks §Phase 1 Hard Gate; FR-005, INV-002]
• CHK019 Are direct instruction synchronization, resolver, guards/workflow declarations, evidence truth, budget truth, proof, and report strictly ordered after Phase 1? [Consistency, Spec/Plan §Mandatory Implementation Phases]
• CHK020 Are stop conditions strong enough to halt all dependent work when amendment validation fails? [Exception Coverage, Spec §Stop Conditions]
• CHK021 Does the parallelization contract forbid phase-gate bypass and same-file concurrent ownership? [Clarity, Spec/Plan §Parallelization Contract; Tasks §Parallel Opportunities]

Branch Topology Requirement Quality

• CHK022 Is dev defined only as repository-wide integration/promotion rather than an ordinary stream default? [Clarity, Spec §Canonical branch roles; FR-008]
• CHK023 Is platform-dev consistently the platform feature base, normal PR target, and diff baseline? [Consistency, Spec §Normal feature routing; Plan §Canonical Branch Topology; FR-009]
• CHK024 Is website-dev consistently the website feature base, normal PR target, and diff baseline? [Consistency, Spec §Normal feature routing; Plan §Canonical Branch Topology; FR-010]
• CHK025 Is cross-stream/promotion work required to declare classification, target, and baseline and allowed to target dev only explicitly? [Clarity, FR-011, FR-012]
• CHK026 Is repository-governance work distinguished from a fourth branch family and explicitly mapped for Spec 439 by affected scope? [Clarity, Spec §Branch and Integration Strategy]
• CHK027 Does the spec state that long-lived branch divergence is not itself a defect? [Ambiguity Prevention, FR-013]
• CHK028 Is website resolver proof distinguished from actual delivery onto website-dev? [Scope, Spec §Branch and Integration Strategy]

Unified Resolver Contract Quality

• CHK029 Are branch-family selection and concrete Git-ref selection defined as two separate decisions? [Clarity, Spec/Plan §Unified Resolver Contract; INV-010]
• CHK030 Is Stage 1 priority exactly explicit family input, PR target, active spec metadata/classification, branch-name plus repository-scope signals, then fail closed? [Consistency, FR-014; Spec/Plan §Stage 1]
• CHK031 Is every explicit family input required to be validated against a known family? [Completeness, FR-015]
• CHK032 Is a known PR target authoritative while still being conflict-checked against other authoritative signals? [Clarity, FR-016]
• CHK033 Are spec metadata, branch naming, and path/scope signals prevented from silently overriding a conflicting valid PR target? [Conflict, FR-017-FR-019]
• CHK034 Is explicit family platform plus PR target website-dev defined as an actionable failure rather than precedence-based override? [Conflict, Spec §Stage 1; BS-010]
• CHK035 Is branch-name-only or ambiguous heuristic classification forbidden? [Ambiguity, FR-018-FR-020; BS-011]
• CHK036 Is Stage 2 priority exactly explicit family-matching ref, matching remote ref, matching local ref, ancestry/merge-base validation, then fail closed? [Consistency, FR-021, FR-022]
• CHK037 Are refs from a different family rejected before merge-base/diff execution? [Exception Coverage, FR-023; BS-012]
• CHK038 Are origin/dev and HEAD~1 explicitly forbidden as platform/website integration fallbacks? [Clarity, FR-024]
• CHK039 Is dev permitted in Stage 2 only after Stage 1 explicitly classifies promotion/cross-stream integration? [Consistency, FR-025]
• CHK040 Are success and failure diagnostics objectively specified, including family, ref, target, merge base, base range, conflicts/attempted refs, override guidance, and no-diff confirmation? [Measurability, FR-026, FR-027]
• CHK041 Do spec and plan use the same resolver priorities, conflict rules, terminology, and examples without an extra ancestry source in Stage 1? [Cross-Artifact Consistency, Spec/Plan §Unified Resolver Contract]

Evidence and Budget Truth Requirement Quality

• CHK042 Is immediate capture and persistence of the original test-process exit required? [Completeness, FR-034]
• CHK043 Is report refresh prohibited from hard-coding or inferring success over stored failure truth? [Clarity, FR-035-FR-037]
• CHK044 Is dual test/report failure required to preserve both contexts and remain failed? [Exception Coverage, FR-038; EF-007]
• CHK045 Are JUnit existence, parse validity, counts, failures, errors, skips, status, and affected path specified? [Completeness, FR-039-FR-041]
• CHK046 Are process/JUnit/report contradictions required to be visible and non-zero? [Consistency, FR-040; EF-005]
• CHK047 Can missing or malformed required JUnit/report evidence never produce success? [Edge Case, FR-041; EF-006]
• CHK048 Are existing valid successful consumers protected through a minimal compatible report extension? [Compatibility, FR-042]
• CHK049 Is TestLaneBudget the sole blocking/advisory authority, with no policy duplication in wrappers/Composer/workflow declarations? [Ownership, FR-043, FR-044]
• CHK050 Are blocking, advisory, threshold-preservation, missing-input, and reusable-entry-point outcomes objectively distinct? [Measurability, FR-045-FR-049; EF-003, EF-004]

Scope, Product Surface, and Proportionality Quality

• CHK051 Is the implementation bounded to governance docs, repository tooling, local evidence/report support, focused tests, and a final report? [Scope, Spec §In Scope]
• CHK052 Are remote branch protection, Gitea administration, deployment gates, remote merge governance, and CI-platform redesign excluded? [Scope, FR-053; Spec §Explicit Non-Goals]
• CHK053 Are product runtime, UI, routes, models, migrations, providers, RBAC, OperationRun, customer output, and website runtime explicitly excluded? [Scope, FR-050]
• CHK054 Are deterministic, network-free, database-free fixtures required without hidden broad context cost? [Non-Functional Coverage, FR-051; Spec §Testing / Lane / Runtime Impact]
• CHK055 Does the proportionality review justify one fixed two-stage resolver and one narrow governance amendment while rejecting a general framework? [Proportionality, Spec §Proportionality Review]
• CHK056 Are Product Surface, browser proof, Human Product Sanity, assets, and deployment consistently N/A with rationale? [Consistency, Spec/Plan Product and Runtime sections]

Task and Implementation-Evidence Quality

• CHK057 Do all numbered tasks include phase, requirement/invariant references, dependencies, exact file/component, and expected evidence? [Task Quality, Tasks T001-T061]
• CHK058 Were all tasks still unchecked at requirements-preparation close-out, with Spec-Correction clearly distinguished from implementation? [Historical State Clarity, Tasks preparation snapshot]
• CHK059 Does the coverage table map FR-001-FR-054, INV-001-INV-020, BS-001-BS-012, and EF-001-EF-007 to tasks? [Traceability, Tasks §Requirement and Evidence Coverage]
• CHK060 Was implementation-report.md reserved for Phase 8 and explicitly absent during requirements preparation? [Historical State Clarity, Tasks Phase 8; Spec §Final Spec Gate]

Post-Implementation Evidence-Contract Correction Addendum

This addendum records the current evidence-contract and baseline-attribution review. It does not rewrite the CHK001-CHK060 requirements-preparation snapshot.

• CHK061 Does the corrected contract preserve the prospective Phase 1 hard gate while defining proportional close-out evidence?
• CHK062 Are the final Constitution amendment, exact amendment boundary, unrelated-scope controls, synchronized dependents, and absence of a conflicting final state repo-proven?
• CHK063 Do tasks.md and implementation-report.md attest the sequence and state explicitly that no pre-mutation historical checkpoint was required or retroactively claimed?
• CHK064 Does the paired baseline attribution use the exact pre-439 SHA, comparable environment and lane selection, raw exits, JUnit documents, and separate artifact checksums?
• CHK065 Are failure/error cases compared as multisets and performance, baseline debt, feature regression, and gate activation kept distinct without changing budgets?
• CHK066 Do T056, T061, the attribution evidence, and the implementation report agree, without describing a failed baseline or feature lane as PASS?

Requirements Quality Result

• Candidate Gate: PASS.
• Requirements quality: PASS.
• Cross-artifact analysis: PASS after corrected spec/plan/tasks/checklist validation.
• Spec Readiness Gate: READY.
• Implementation Authorization: AUTHORIZED.
• Constitution-Amendment Posture at preparation close-out: IN SCOPE AS MANDATORY PHASE 1; NOT YET IMPLEMENTED.
• Requirements quality complete: yes.
• Implementation performed at preparation close-out: no.
• Implementation complete at preparation close-out: no - NOT STARTED.
• Implementation report created at preparation close-out: no.
• Test execution claimed by this requirements snapshot: no.
• Requirements review outcome class: acceptable-special-case.
• Test-governance preparation outcome: document-in-feature.
• Next action recorded at preparation close-out: Start a separate Spec 439 implementation loop at Phase 0, then execute and validate Phase 1 before any dependent task.