Appendix L: Product-Scale Planning + Cross-Consistency Review
Operational procedure: skill:s4u-product-scale-planning; overview: methodology §5.6. This reference supplies the evidence record and an example. It does not ship a scheduler, general plan parser, approval service or cross-plan semantic validator.
Why this is in its own appendix
Planning spans business intent, technical decisions, delivery and existing systems. A short review record makes their dependencies inspectable without pretending every future requirement is known. Reuse the enterprise's authoritative backlog, glossary, architecture register and evidence store. One interface can present those records without replacing their owners.
Check source classification, destination readers and sharing authority before copying evidence into a plan or report. Private exploratory material, customer information and proprietary source are not made shareable by summarizing them or adding a public label. Use approved extracts and scoped references; assess exports, generated pages and indexes too.
The Process: From Empty Project to /loop-Ready
The historical heading does not limit this procedure to new projects or require /loop. For both new and existing systems, map these information needs to their actual homes:
| Information | Current milestone | Nearby milestone | Distant option |
|---|---|---|---|
| Intent and acceptance | Exact approved baseline plus explicit unresolved exclusions | Proposed outcomes, examples and named decision dependencies | Hypothesis, user value and uncertainty |
| Architecture / integrations | Accepted decisions and verified or blocked contracts | Intended interfaces and producer dependencies | Alternatives to investigate |
| Delivery design | Scoped tasks, owners, verification, permitted effects and resources | Slice/wave shape and acceptance expectations | Goal, dependencies and review trigger |
| Authority / evidence | Current mandate, version-bound approvals and test receipts | Approval/verification still needed | Decision owners, not fabricated approval |
A PRD can hold the product narrative; a maintained work tracker owns priority and blockers. An optional STATE.md generated snapshot is repository evidence, not that tracker or the deployed system. Do not create a second master merely to satisfy an artifact count.
A draft decision is acceptable in a roadmap when its dependency is explicit. The dependent implementation remains blocked until the required approval is available; independent work can proceed within scope. No fixed “five-minute checkpoint” or planning-time speedup is promised.
The BA reviews mined or contributed knowledge, the owner accepts its business meaning, and engineering proceeds only when its own prerequisites and mandate are satisfied. Discoveries can interrupt a milestone immediately; they need not wait for its scheduled end.
The Cross-Consistency Review Checklist
Review the relevant baseline and planned changes as a discrete activity before dependent execution, and repeat affected checks when inputs change. Existence of a report proves only that a file exists.
For every check, record: exact source/plan revisions; expected relationship; actual evidence and method; pass/fail/unassessed/not-applicable with rationale; affected tasks; finding owner; approval/exception reference; recheck trigger. A report should state both checked scope and exclusions.
Check A — ADR↔plan↔baseline-migration cross-reference integrity (mechanical)
This includes structural lookup and semantic review; “mechanical” is not a claim that grep establishes effective state.
- A.1–A.3: Resolve existing decision IDs, approval evidence and exact supersession links. Distinguish future proposed decisions from accepted prerequisites. Use the existing register and numbering policy.
- A.4–A.5: Establish the resulting schema at the selected migration revision, including subsequent rename/drop/constraint operations. Alternatively identify the producer task and require its verification before consumers run. Historical occurrence of a name is insufficient.
- A.6: Cite actual existing migration revisions and filenames precisely. Future tasks identify purpose and ordering; allocate new identifiers through the project's controlled process.
- A.7: Check effective nullability, defaults, uniqueness, authorization and other constraints relevant to the planned operation. Do not substitute a different business predicate to make a query fit.
- A.8: Existing scaffolding or an explicit earlier scaffold task can satisfy a dependency. Missing directories need not invalidate a future sketch.
- A.9: Test fixtures must fit the real data/schema contract and represent the intended role/outcome. Include nonempty selection evidence; an empty suite is not proof.
Use source inspection and authorized disposable-environment checks as needed. Merely reading this plan does not authorize executing application code, real migrations or provider calls.
Check B — Plan capability handoffs (mechanical)
Include existing verified capabilities, modifications to existing modules, and planned new capabilities. A file inventory is a discovery aid, not the capability contract.
A handoff record identifies provider, consumer, version, semantics, permissions, failure/retry behavior, producer task or baseline evidence, and the owner of acceptance. A mock or twin supports development but does not establish the current real provider contract. Required external verification remains unassessed until authorized evidence exists.
Check C — Decision contradictions across plans (judgment)
Compare the same property within the same domain, version, environment and rollout stage. Distinct supported legacy/new-system behavior can be intentional; document its approved rationale and compatibility obligation.
When a genuine contradiction affects business meaning or a security boundary, preserve the accepted baseline and route an amendment to the accountable owner. Neither “pick one” nor an AI-generated justification constitutes approval. Changes can invalidate dependent reviews and pending approvals.
Check D — Canonical stack drift (mechanical)
Compare against the adopted method/stack/control profile and approved exceptions. A different approved enterprise stack is not a defect. Pin the profile revision; preserve accepted ADR history through explicit supersession or a factual erratum as appropriate.
General validators for Checks A/B/D/E described in earlier editions are not implemented. The shipped register/freshness/schema tools check only their stated subjects. A manual review may be valid evidence when its actual sources, method and limitations are recorded; do not claim an unbuilt script ran.
Check E — Roadmap dependency consistency (mechanical)
Check dependency order together with current priority, authorized scope, business-owner capacity, implementation resources, external availability and evidence readiness. A milestone date does not reserve any of those.
Record checkpoints before dependent milestones and immediate invalidation triggers within them. Confirm any recurring execution mechanism separately, using s4u-loop-dispatch; this document does not arm it.
The Bounded-Autonomy Checkpoint Shape
| Field | Required content |
|---|---|
| Subject | Project, completed/current and proposed-next slice, exact intent/plan/candidate versions |
| Outcomes | Delivered business behavior distinguished from commits, builds and deployment |
| Evidence | Actual checks, selected cases, environment, result receipts and unassessed gaps |
| Discoveries | Changed assumptions, disputed rules, legacy/provider drift, incidents and unsupported requests |
| Impact | Affected dependencies, scope, risks, cost/capacity and required amendments |
| Decision | Accountable role, exact plan revision, proceed within scope / amend / halt, rationale and recorded authority |
| Next action | Bounded authorized work, outstanding approval and next review trigger |
Do not reduce the checkpoint to commit counts or coverage deltas. No response is not approval. Authority to proceed with design or coding is not authority to release, process new categories of data or activate a changed policy.
Worked Example: M5 → M6 (planned)
Synthetic scenario: an existing eligibility service changes slowly, but an urgent fix alters an observed exception rule while its replacement is being developed.
- M5 pins the existing source/runtime evidence and records extracted rules as observations. The BA and domain owner establish which interpretation is intended; code is not automatically policy.
- M6 intends to consume a rule contract from M5. A late urgent fix arrives through the agreed notification/reconciliation path. Its source, affected version and uncertainty are recorded.
- The team assesses whether the fix changes the approved rule or only corrects the old implementation. Only affected work pauses; the business owner reviews proposed meaning changes.
- If approved intent changes, create a new baseline, update the producer/consumer and acceptance dependencies, reassess compatibility with supported legacy work, and obtain required approval for the new revision.
- M6 can proceed only when its dependencies are verified. A passing old mock, an importable module or a green documentation build cannot substitute for those receipts.
The cadence is proportionate: a slow legacy system can use urgent-fix/release notifications plus periodic reconciliation. Missing notifications remain a declared gap, not assumed continuous observation.
Summary
Plan with enough detail to test the next important uncertainty, retain traceable decisions and replan when evidence changes. The seven cross-consistency concerns in §5.6 are operationalized above; they are not a claim of seven shipped automated gates. Useful preparation reduces avoidable rework, but neither a PRD nor this methodology guarantees a multi-day autonomous delivery schedule.