Software Factory Runtime and Autonomy Grill Log

Sources:

• User clarifications and accepted directions on 2026-08-27.
• /private/tmp/harness-intelligence-software-factory-resumption-handoff-20260827.md.
• Original software-factory task lineage 019fae1f-3134-7fa2-8def-09fb7f278e43.
• Executable Harness Finder, Requirements, Design, Delivery, and worker-wave skills.
• Closed Project Backlog Operating Model and Agent Workflow Architecture, Rules, and Autonomy grills.
• Executor official documentation and fetched source for proxy, policy, and Cloudflare deployment behavior.

Starting Model

The human closes the decision frontier and produces accepted backlog. The factory then manages one parent Codex agent that runs the existing Harness delivery graph and orchestrates ordinary scoped workers inside that thread. Executor gates integration tools and credentials. Herdr exposes the live system.

Accepted Starting Decisions

Q1

Question: Does autonomous delivery reuse Harness Full Delivery or introduce a separate factory delivery graph?

Accepted answer:

• Reuse Harness Full Delivery.
• It continuously re-enters routing through its ordinary in-bounds phases and bounded review loop.
• The factory supplies admission, runtime, persistence, and operation around that graph; it does not duplicate the graph.

Q2

Question: What agent topology runs delivery?

Accepted answer:

• One factory-managed Main Factory Agent owns the delivery thread.
• It orchestrates Harness's existing plan-derived scoped worker subagents inside that thread.
• Reject the fixed Vercel four-agent topology as product architecture.

Q3

Question: What is the integration security gateway?

Accepted answer:

• Self-host Executor as a Cloudflare Worker behind Cloudflare Access.
• Executor owns integration credentials and tool-policy enforcement.
• Executor does not replace command, filesystem, resource, network, or workload isolation.

Q4

Question: What persistent Unix identity owns the factory control plane?

Accepted answer:

• Use a dedicated factory Unix user with its own home, expected to be /home/factory on Debian.
• Do not reuse Stefan's or Simone's Unix identity, home, credentials, or manual environment lifecycle.

Round R1

Current frontier: Q5-Q9. All five are independent. Their answers unlock the detailed admission, state, retry, concurrency, policy, and operator branches.

Q5 — Factory Delivery Run unit

Question: What backlog object owns one autonomous Factory Delivery Run?

Recommendation:

• One Story owns one run.
• Its agent-ready SPEC.md defines the accepted goal; its required Tasks and blockers become the plan/worker execution graph inside that run.
• Do not create one parent run per Task: Tasks are already the atomic worker and dependency units.
• Do not use an Epic or milestone as one run: either can span several independently shippable Stories.

Why:

• The accepted backlog model defines Story as one shippable product outcome, Technical Finder as one agent-ready spec per Story, and Tasks as required atomic work beneath it.
• This preserves one parent agent, one bounded goal, and one coherent review lineage.

State: open.

Q6 — Successful terminal outcome

Question: Which evidence marks a successful Factory Delivery Run as complete: reviewed pull request, merge, staging, or production?

Recommendation:

• For v1, end the agent run at an approved, validated, review-clean pull request with tracker and documentation closeout complete.
• Treat merge, release, staging, and production as separate automation or separately accepted authority until their exact repository and deployment gates are designed.
• Keep production evidence as the independent condition that completes the originating Fog.

Why:

• Current Full Delivery has a strong PR/review/docs/tracker closeout contract.
• The accepted backlog model explicitly parks CI/CD design and distinguishes pull request, merge, staging, and production facts.
• Automatic production mutation would otherwise be an invented authority expansion.

State: open.

Q7 — Executor approval semantics

Question: When Executor returns require_approval, should the factory wait for an operator, fail the run, or treat the action as already authorized by Full Delivery?

Recommendation:

• Ordinary operations required by accepted Full Delivery should be explicitly allowed by the factory policy; they should not produce approval prompts.
• block remains a hard policy denial.
• require_approval transitions the run to durable Human Steering Required, raises attention in Herdr, and waits for an explicit operator decision.
• Never have the Main Factory Agent approve its own gated call.

Why:

• This keeps ordinary Full Delivery uninterrupted while preserving a real human boundary for exceptional or high-impact tools.
• It avoids making policy prompts an accidental routine phase boundary.

State: open.

Q8 — Git transport credentials

Question: How should git fetch, push, and pull-request branch transport authenticate?

Recommendation:

• Use a GitHub App installation token minted for each Factory Attempt and scoped to the target repository.
• Inject it only into that attempt's Git credential path and erase it during attempt cleanup.
• Keep GitHub API/MCP calls behind Executor; do not expose a long-lived personal token or Executor's stored upstream credential to the shell.

Why:

• Git transport does not automatically pass through an MCP proxy.
• A short-lived repository-scoped token limits cross-run and cross-repository leakage.

State: open.

Q9 — Command and filesystem execution boundary

Question: Where should the Main Factory Agent and its worker subagents execute shell commands and share repository files?

Recommendation:

• Keep the persistent orchestrator, Codex thread process, and Herdr attachment on Hetzner under the factory identity.
• Give each Factory Attempt one isolated, disposable Factory Workspace shared by its parent and workers.
• Do not treat /home/factory alone as a sufficient multi-run sandbox. The concrete sandbox provider can remain Sandcastle-backed, including Cloudflare Sandbox when it satisfies Git, process, filesystem, and callback needs.

Why:

• Parent and workers need one shared filesystem to preserve the existing worker-wave model.
• Per-attempt disposal prevents one run from reading another run's checkout, generated credentials, or residue.
• A Unix user protects the host from human accounts but does not isolate concurrent or sequential factory runs from one another.

State: open.

Deferred Until R1 Answers

• Exact Factory Admission predicate and provider field/state.
• Claiming, deduplication, and one-active-run rules.
• Trigger mechanism: polling, webhook, queue, or explicit operator dispatch.
• Run/attempt/job naming and how much of the old task → run → job → attempt vocabulary survives.
• Retry limits, backoff, cancellation, and orphan cleanup.
• Global and repository concurrency.
• Executor policy ownership, connection patterns, and credential rotation.
• Herdr command authority and whether Backoffice retains a durable factory graph.
• Evidence retention and the final Neon/XState schema.

Grounding Notes

• delivery-phase is already the continuous lifecycle router. In Full Delivery it invokes review as an authorized inner step and stops only at closeout, a real blocker, or durable human_steering_required.
• implement-spec already uses one parent orchestrator and plan-derived worker waves. Provider Tasks may retain stable identity without becoming separate parent agent runs.
• The Project Backlog Operating Model fixes Product Area → Initiative → Epic → Story → required Task. A Technical Finder result includes one agent-ready spec per Story plus Tasks and blockers.
• Executor policy matching is connection-aware and uses the most restrictive matching policy. Supported actions are allow, require approval, and block.
• Executor's Cloudflare deployment protects the HTTP/MCP surface and stored integrations. It does not define the factory's Git transport or workload sandbox.
• The public AFK wiki page still describes obsolete manual review/resume stops. Executable delivery-phase is current authority and must be reflected during later docs ingest.