Define separate status, next, and brief contracts

[nothingnesses]

This issue records a proposal. Implementation requires a selected work brief and separate execution approval.

Background and problem

Current status projects every step and dependency. Current next projects active units and selected prose. Neither supplies the retained ready/blocked and per-role separation.

Proposal

Define three read-only contracts:

• status for state inspection.
• next for ready and blocked work.
• brief for bounded per-step, per-role context.

Produce example human and JSON outputs against current work-state fixtures. Identify which examples require a later state-model change.

Scope and exclusions

Keep this separate from role execution. Exclude:

• run.
• Automatic selection changes.
• Shipped role edits.
• Legacy removal.

Briefs retain:

• Scope and acceptance.
• Relevant source references.
• Bounded reminders to inspect current repository evidence.

They grant no execution authority.

Acceptance criteria

• Each command has a distinct purpose and explicit input authority.
• Examples cover:
  • Ready work.
  • Blocked work.
  • Completed work.
  • Invalid inputs.
  • Oversized inputs.
• Repeated projections are deterministic and reject excess output without truncation.
• Existing source and output limits remain until separately revised.
• Missing runner information remains explicitly unavailable rather than inferred.

Alternatives and open questions

Extending next avoids another command but combines selection and worker context. The separate contract is recommended under One source of truth and Keep changes small and reviewable.

Prompt-effectiveness evaluation remains a separate proposal.

References

• decision report.
• next projection.
• status projection.
• command declarations.
• D-013.
• D-034.
• D-065.
• D-067.