Agent Workflow Architecture, Rules, and Autonomy Grill Log

Source: CTO meeting on 2026-08-13 and user clarifications on 2026-08-14.

Branch: Technical Requirements Grilling

Q1

Prerequisites:

• none

Question: Must technical design be a separate named grilling phase?

Accepted answer:

• No. Technical decisions join the same dependency-ordered design tree as behavioral and product decisions.
• The grill may move from behavior into architecture as prerequisites settle; it does not expose a mandatory two-phase ceremony.

Q2

Prerequisites:

• Q1

Question: Does domain-modeling pressure-test implementation and architecture details?

Accepted answer:

• Yes. Remove wording that makes domain-modeling appear limited to abstract terminology or behavior.
• Domain-modeling challenges code-level and architectural consequences during the live interview.

Q3

Prerequisites:

• Q1

Question: How explicit should requirements-grill be about technical architecture?

Accepted answer:

• Keep the skill generic and concise.
• Lightly require codebase-grounded technical closure across concerns such as topology, dependency graphs, seams, boundaries, persistence, and relevant module, service, or component structure.
• Do not turn the skill into a literal exhaustive architecture checklist.

Q4

Prerequisites:

• Q2
• Q3

Question: Which lifecycle stage first decides the target architecture?

Accepted answer:

• Requirements grilling decides and validates the target architecture when the work is architecture-bearing.
• create-spec compiles the accepted decisions.
• create-plan derives execution structure from them instead of inventing the target architecture.

Branch: Project Codebase Rules

Q5

Prerequisites:

• none

Question: How are project-specific rules authored after scaffold commands?

Accepted answer:

• Add a small, fast, granular rule-authoring skill.
• Use it in the post-command scaffold continuation alongside writing-for-agents, before final scoped guidance is authored.

Q6

Prerequisites:

• Q5

Question: Where do project-specific rules live?

Accepted answer:

• The repository-owned rule surface is .agents/rules/.
• Detailed codebase patterns move there instead of accumulating in scoped AGENTS.md files.

Q7

Prerequisites:

• Q6

Question: How do scoped AGENTS.md files reach project rules?

Accepted answer:

• Scoped AGENTS.md files remain concise indexes and reference the central .agents/rules/ surface.
• They do not duplicate detailed rule bodies.

Q8

Prerequisites:

• Q6

Question: How are rules activated and checked?

Accepted answer:

• Activate rules with deterministic scope/path and task triggers.
• Tags support grouping and discovery; tags alone are not activation authority.
• Evaluate each activated rule independently and report pass, fail, or not-applicable with evidence.

Branch: Delivery Autonomy

Q9

Prerequisites:

• none

Question: What is the default continuation behavior for full delivery?

Accepted answer:

• Full delivery automatically re-enters routing after every completed phase and continues through closeout.
• It does not request confirmation between ordinary in-scope steps.

Q10

Prerequisites:

• Q9

Question: When does delivery stop at a human checkpoint?

Accepted answer:

• HITL is opt-in only when the user explicitly requests a checkpoint.
• This supersedes Q2 and the completion axiom in the closed Delivery Phase Progressive Routing grill wherever they made stopping after a phase an ordinary full-delivery outcome.
• Progressive one-phase loading and durable resumable handoffs remain accepted.

Round R1 Decisions

Q11

Prerequisites:

• Q1
• Q3

Question: Which work requires deep technical grilling?

Accepted answer:

• Every grill assesses technical consequences.
• Deep technical and architecture closure is required only when the work is code-bearing or architecture-bearing.
• Pure copy, content, or policy work does not manufacture an architecture branch when the assessment finds no technical consequence.

Q12

Prerequisites:

• Q2

Question: Where are accepted implementation details persisted?

Accepted answer:

• GLOSSARY.md remains a glossary and does not become an implementation or architecture artifact.
• Domain-modeling still grills implementation details during the live session.
• Accepted architecture is persisted through the grill artifacts and compiled into SPEC.md.

Q13

Prerequisites:

• Q7
• Q8

Question: What remains inline in each scoped AGENTS.md?

Accepted answer:

• Keep the concise scope boundary, exact skill-routing table, and one exhaustive pointer to .agents/rules/.
• Codebase patterns and detailed invariants live in the Rule Registry rather than inline prompt prose.

Q14

Prerequisites:

• Q6
• Q8

Question: How is .agents/rules/ physically organized?

Accepted answer:

• Use one central .agents/rules/index.md.
• Group granular rule files by stable repository scope and give each Codebase Rule a stable id.

Q15

Prerequisites:

• Q8

Question: What evidence may establish a Codebase Rule?

Accepted answer:

• Current executable Code Evidence may establish a rule.
• An explicitly accepted architecture decision may also establish a rule when the rule links to its durable decision source.
• Taste or documentation without one of those authorities cannot establish a rule.

Q16

Prerequisites:

• Q5
• Q6

Question: Who owns authored rule files?

Accepted answer:

• Authored Codebase Rules are project-owned and preserved.
• Harness owns the Rule Authoring Skill, schema, template, and post-command handoff contract, not the resulting project-specific rule content.

Q17

Prerequisites:

• Q5
• Q16

Question: When is the Rule Authoring Skill invoked after initial scaffold?

Accepted answer:

• Invoke the Rule Authoring Skill only from post-command handoffs.
• The supported command outcomes are scaffold and update.
• Do not make it a general automatic step of later implementation or architecture work.

Q18

Prerequisites:

• Q7
• Q17

Question: Does later delivery migrate Harness's current prompts into the new rule model?

Accepted answer:

• Yes. Use Harness as the first proving migration.
• Put migration behavior in a progressively disclosed inner reference of the Rule Authoring Skill.
• The migration reference owns how existing scoped guidance is classified and moved into the Rule Registry without duplicating rule bodies.

Q19

Prerequisites:

• Q9
• Q10

Question: Does autonomous delivery retain the three-review ceiling?

Accepted answer:

• Yes. Full Delivery permits at most three complete review passes.
• After the third repair, run focused validation instead of starting review four.
• Passing focused validation resumes Full Delivery toward closeout.
• A terminal failure is a blocker, not a HITL Checkpoint.

Q20

Prerequisites:

• Q9
• Q10

Question: Which external actions inherit full-delivery authorization?

Accepted answer:

• Full Delivery has full permission for every operation required by its inner selected steps.
• Authorization is bounded by the delivery graph and accepted goal; it is not divided by local versus remote action class.
• Full Delivery cannot perform unrelated work outside its inner steps.
• Missing access or unavailable authority is a technical blocker, not a request for confirmation.

Final Consistency Pass

• The three branches use one consistent lifecycle: requirements closes applicable behavior and architecture, specification compiles accepted decisions, planning derives execution, and Full Delivery executes without confirmation stops.
• GLOSSARY.md remains the glossary while grill artifacts and SPEC.md own accepted architecture. No artifact has two competing owners.
• Scoped AGENTS.md files remain concise routers. The project-owned Rule Registry owns detailed Codebase Rules, while the Harness-owned Rule Authoring Skill owns creation and migration behavior.
• The Rule Authoring Skill runs only in scaffold and update post-command handoffs. Its migration inner reference applies that same contract to current Harness guidance as the proving case.
• Full Delivery permission is exhaustive inside selected inner steps and absent outside them. The three-review ceiling bounds full review passes without creating a confirmation gate.
• No accepted term, relationship, axiom, or branch decision conflicts with another. No design branch remains open or parked.

Shared Understanding Confirmation

• Confirmed by the user on 2026-08-14 after presentation of the persisted locked direction, glossary, relationships, axioms, and delivery bounds.
• All three branches are closed at 100%; no branch is open or parked.

Glossary Decisions

Glossary Q1

Question: Which terms describe the new workflow?

Accepted answer:

• Canonical term: Technical Grill Branch — the codebase-grounded design decisions that become reachable inside the normal requirements design tree.
• Canonical term: Codebase Rule — one independently testable, repository-specific pattern or invariant.
• Canonical term: Rule Registry — the .agents/rules/ surface that indexes and progressively discloses Codebase Rules.
• Canonical term: Rule Authoring Skill — the small post-command skill that derives and maintains the Rule Registry from accepted authority.
• Canonical term: Rule Evaluation Ledger — per-rule pass | fail | not-applicable evidence for one task.
• Canonical term: Full Delivery — uninterrupted delivery routing through closeout inside accepted goal bounds.
• Canonical term: HITL Checkpoint — a manual delivery stop explicitly requested by the user.