Skip to content

Planning Carries Only Asked-For Scope #284

Description

@sameera

Epic: Planning Carries Only Asked-For Scope

⚠️ Utilization risk: assessed L (1–2 weeks). Fills the sprint with no slack for overruns. Watch for scope creep.

Description

Every gate in the epic stage today measures effort or testability. The sizing rubric asks how big the work is. The sharpness precondition asks whether the split is knowable. The complexity rollup asks whether it fits one epic. The epic gate asks whether an acceptance criterion can be verified. Not one of them asks whether anyone requested the scope in the first place. The concept page for the epic approval gate states the gap in its own third invariant: open questions are the only pre-filing safeguard.

The result is scope nobody asked for, filed as binding acceptance criteria. In the observed failure the epic body specified implementation mechanism as acceptance criteria, tabulated all three canonical personas under a heading whose own rule says to tabulate only deviations, ran its out-of-scope list to eleven items, and gave a single story seven acceptance criteria, one of them covering an air-gapped deployment nobody had mentioned. Each addition looked defensible on the page. None of them traced to anything the lead said.

This epic adds the missing axis, as one named rule set this epic calls the razor. The razor holds four kinds of rule. A provenance rule labels every acceptance criterion, assumption, and out-of-scope item as either asked, carrying a quoted fragment of the source text, or inferred. Counted limits bound how much a drafted artifact may contain. Content rules bound what may appear in it at all. One necessity question asks which stories the smallest usable version of the capability needs. The provenance rule is the load-bearing one, because it turns a judgment the drafting model is motivated to answer one way into a comparison anyone can check. The rules then become enforceable at the epic gate and actionable at the approval digest, where reducing scope becomes a single choice rather than a hand edit and a re-run. The value is that a reviewer can see what the model added and delete it cheaply, which is the only condition under which anyone actually does.

Success Metrics

  • Every acceptance criterion, assumption, and out-of-scope item in a drafted epic is either traceable to a quoted fragment of the source text or visibly marked as the drafting model's own addition. There is no third state.
  • A reviewer reduces the scope of a drafted epic at the approval digest in one action, without editing a file or re-running the command.
  • A draft that exceeds one of the razor's counted limits does not reach the approval digest, so a counted limit is enforced rather than advised. Only the acceptance-criteria count admits a stated reason.
  • Re-running the stage on the intent behind the observed failure produces an epic with no acceptance criterion naming a mechanism and no personas table.

Personas

Per docs/product/context.md.

Assumptions

  • The razor is written down once as a shared authoring skill that every drafting stage loads, rather than restated inside each command. Three copies of one rule set diverge, and the divergence is undetectable. The gate would check against one stage's copy while another stage drafted under its own. The prose style shipped in epic #414: Prose translation agent with a resident density convention #422 already set this split: its form rules live in one component, the nxs-prose agent, and each drafting command carries only the short block of rules that component cannot apply. The razor follows the same split, so its normative home is an established shape rather than a new one. The skill is still the first guidance-only skill in the components tree, because the razor's rules are loaded by the stage that drafts rather than delegated to an agent that acts.
  • Provenance labels serve the epic gate and the approval digest, and do not reach the filed issue bodies. A durable reader is not asked to read planning bookkeeping.
  • The mechanical checks are one shared deterministic operation in the existing toolkit, which the epic gate and the other drafting stages invoke. No new agent is created.
  • The working name of the skill the razor is written down in may change during implementation without changing this scope.

Out of Scope

  • Changing the sizing rubric, the sharpness precondition, or the stub decomposition path. Each of them measures effort and works as intended.
  • Retrofitting epics that are already filed.
  • A second reviewing agent that judges necessity. The mechanical checks and the reviewer at the digest carry that work between them.
  • Applying the razor to the close and distill stages.

Open Questions

None.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    epicEpic (created by nxs-gh-create-epic)in-progressDesign filed; approval is the close of the record sub-issue

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions