Spec: Technical Requirements, Project Rules, and Autonomous Full Delivery

Context

Repository teams and agents use Harness setup and Full Delivery to turn accepted requirements into implementation. The current requirements workflow can close behavior while leaving technical architecture for planning, scoped AGENTS.md files can accumulate detailed project patterns, and delivery can stop for confirmation between otherwise authorized steps.

This capability closes applicable technical design during requirements grilling, makes project-specific patterns independently discoverable and testable through a project-owned Rule Registry, and makes Full Delivery continuous within its accepted goal and selected inner steps.

Non-Goals

• Requiring a separate named architecture phase or a fixed two-phase grill.
• Requiring deep architecture work for copy, content, policy, or other work whose technical assessment finds no code or architecture consequence.
• Turning GLOSSARY.md into an implementation or architecture artifact.
• Embedding detailed Codebase Rules in scoped AGENTS.md files.
• Using tags as the sole authority for rule activation.
• Treating taste or unsupported documentation as authority for a Codebase Rule.
• Running the Rule Authoring Skill outside scaffold or update post-command handoffs.
• Granting Full Delivery permission for work unrelated to its accepted goal or selected inner steps.
• Adding an ordinary confirmation stop between Full Delivery phases.
• Defining planning files, commands, workers, task order, or migration waves.

User Stories

US-001: Close applicable technical design during requirements grilling

As a repository team, I want requirements grilling to test technical and architecture consequences when work affects code or architecture so the resulting specification contains an accepted target design.

US-002: Derive execution from accepted architecture

As a planning agent, I want the specification to compile the architecture accepted during grilling so planning derives execution instead of inventing the target architecture.

US-003: Maintain granular project-owned guidance

As a repository team, I want project-specific patterns preserved as granular Codebase Rules so scoped guidance remains concise and the rules scale without becoming a prompt dump.

US-004: Activate and evaluate rules deterministically

As a working agent, I want applicable Codebase Rules selected by deterministic triggers and evaluated independently so rule compliance has specific evidence.

US-005: Author rules from scaffold and update handoffs

As a repository team, I want scaffold and update post-command handoffs to maintain the Rule Registry from accepted authority so generated guidance reflects stable project patterns without taking ownership of project content.

US-006: Complete delivery without confirmation stops

As a user who selects Full Delivery, I want it to continue through its inner steps and closeout with the required authority so I do not need to confirm each phase transition.

US-007: Bound autonomous review without adding HITL

As a user running Full Delivery, I want review and repair to have a deterministic ceiling and terminal behavior so autonomous execution cannot enter an endless review loop.

Acceptance Criteria

• AC-001: Every requirements grill records whether the work has technical consequences.
  • Covers: US-001
• AC-002: When work is code-bearing or architecture-bearing, requirements closure includes codebase-grounded technical design across the applicable topology, dependencies, seams, boundaries, persistence, and module, service, or component concerns without requiring a separately named phase.
  • Covers: US-001
• AC-003: When the technical assessment finds no code or architecture consequence, the grill can close without manufacturing a Technical Grill Branch.
  • Covers: US-001
• AC-004: Domain-modeling pressure-tests implementation and architecture consequences during the live grill while GLOSSARY.md remains glossary-only.
  • Covers: US-001
• AC-005: Accepted architecture appears in the grill artifacts and compiled SPEC.md, and planning consumes that authority rather than establishing a competing target architecture.
  • Covers: US-002
• AC-006: The project-owned Rule Registry has one central index and granular Codebase Rules grouped by stable repository scope with stable identifiers.
  • Covers: US-003
• AC-007: Each scoped AGENTS.md retains its scope boundary, exact skill-routing table, and one exhaustive Rule Registry pointer without duplicating detailed Codebase Rule bodies.
  • Covers: US-003
• AC-008: Each Codebase Rule is established by current executable Code Evidence or links to a durable explicitly accepted architecture decision.
  • Covers: US-003, US-005
• AC-009: Rule activation uses deterministic scope, path, and task triggers; tags support grouping and discovery without acting as the sole activation authority.
  • Covers: US-004
• AC-010: Every activated Codebase Rule receives one evidence-backed pass, fail, or not-applicable result in the Rule Evaluation Ledger.
  • Covers: US-004
• AC-011: Scaffold and update post-command handoffs invoke the Rule Authoring Skill alongside writing-for-agents, and no other workflow invokes it automatically.
  • Covers: US-005
• AC-012: Authored Codebase Rules remain project-owned and preserved while Harness owns the Rule Authoring Skill, schema, template, and post-command handoff contract.
  • Covers: US-003, US-005
• AC-013: The Rule Authoring Skill contains a progressively disclosed migration reference that classifies current Harness scoped guidance and moves detailed patterns into the Rule Registry without duplicated rule bodies.
  • Covers: US-005
• AC-014: Full Delivery re-enters routing after every completed phase and continues through closeout without requesting confirmation between ordinary in-bounds steps.
  • Covers: US-006
• AC-015: Full Delivery has permission for every operation required by its selected inner steps and accepted goal, while unrelated work remains outside that authority.
  • Covers: US-006
• AC-016: A HITL Checkpoint occurs only when the user explicitly requested it; missing access, unavailable authority, or terminal failure is reported as a blocker instead of a confirmation request.
  • Covers: US-006, US-007
• AC-017: Full Delivery performs at most three complete review passes; after the third repair it runs focused validation instead of review four.
  • Covers: US-007
• AC-018: Passing focused validation after the third repair resumes Full Delivery toward closeout, while terminal validation failure reports a blocker.
  • Covers: US-007

Constraints

• Technical depth remains integrated into the ordinary dependency-ordered requirements design tree.
• Requirements-grill describes applicable architecture concerns lightly and generically rather than as an exhaustive checklist.
• GLOSSARY.md owns glossary language; grill artifacts and SPEC.md own accepted architecture.
• Codebase Rule activation is deterministic and each verdict is independent.
• Rule content is repository-owned and must survive scaffold and update.
• Full Delivery authorization follows its accepted delivery graph, independent of whether a required operation is local or remote.
• Progressive one-phase loading and durable resumable handoffs remain in force.

Dependency Readiness

No Stack Required

Branch/Base Intent

Not applicable

Accepted Technical Decisions

• The Technical Grill Branch is part of the normal requirements design tree and becomes deep only for code-bearing or architecture-bearing work.
• Technical closure is codebase-grounded and considers applicable topology, dependency graphs, seams, boundaries, persistence, and module, service, or component structure without imposing one universal checklist.
• create-spec compiles accepted behavior and architecture; create-plan derives execution structure from that authority.
• .agents/rules/ is the project-owned Rule Registry. It has one central index and scope-grouped granular Codebase Rules with stable identifiers.
• Scoped AGENTS.md files are concise indexes containing scope, exact skill routing, and an exhaustive Rule Registry pointer.
• Code Evidence and durably linked accepted architecture decisions are the only accepted authorities for Codebase Rules.
• The Rule Authoring Skill is small and runs only in scaffold and update post-command handoffs alongside writing-for-agents. Its migration reference uses current Harness guidance as the first proving migration.
• Full Delivery continuously re-enters routing with complete permission inside its accepted goal and selected inner steps.
• Full review is limited to three passes. Focused validation replaces a fourth pass and remains inside the uninterrupted Full Delivery flow.

Accepted Testing Decisions

• Verify technical-grill applicability with one code-bearing or architecture-bearing case and one case with no technical consequence.
• Verify that accepted architecture is present in grill and spec output while GLOSSARY.md remains glossary-only and planning receives the compiled target.
• Verify scaffold and update post-command handoff output both invoke the Rule Authoring Skill and preserve project-owned rule content.
• Verify generated scoped guidance contains the required concise routing content and does not duplicate detailed rule bodies.
• Verify deterministic rule activation and one evidence-backed ledger verdict for every activated rule.
• Verify Full Delivery traverses phase boundaries without confirmation, honors only explicit HITL Checkpoints, and keeps authority inside selected inner steps.
• Verify review routing stops at three complete passes, replaces review four with focused validation, and either resumes closeout or reports a blocker.

Verification Seams

• Observable scaffold and update post-command handoff output.
• Generated scoped AGENTS.md guidance and the project-owned Rule Registry.
• The Rule Evaluation Ledger produced for activated Codebase Rules.
• Requirements-grill artifacts, GLOSSARY.md, and compiled SPEC.md at the requirements/specification boundary.
• Full Delivery phase-routing, HITL, permission, review, validation, blocker, and closeout state transitions.

Decision Log