Software factory planning and implementation slice 1. Prompts and Responses.

Exchange 1

User prompt

Review the existing software-factory research and linked references. Propose an initial “naive” software-factory pattern for this repo, deployed on exe.dev for webhook routing and potentially isolated coding-agent work.

Coding should be handed off to Codex or OpenCode—not a newly built coding agent. Plan how agent sessions are isolated, created, and cleaned up, while leaving room for future remote/sandbox execution.

Create a single-page HTML proposal covering flexible intake/triage, factory phases/components, Neondeck integration, and existing functionality that should be reused, adapted, or removed.

Final agent response

Created a single-page proposal covering flexible intake, factory phases, Codex/OpenCode sessions, isolation and cleanup, exe.dev deployment, and reuse/adapt/retire decisions. It recommends reusing Neon’s delivery cockpit, adding durable intake/coordinating state, and delegating factory coding to external harnesses.

Exchange 2

User prompt

So does ingest get triaged by a small classifier model/task/job ?

Final agent response

Yes—a small, bounded triage job after deterministic filtering:

Code handles admission: validate signatures, deduplicate events, fetch current issue state, resolve the repo, and check eligibility.
A lightweight Neon/Flue task classifies eligible work: implement, investigate, clarify, duplicate, defer, or decline. It returns structured output with rationale, priority, and missing information.
The coordinator persists that decision and routes the item. Uncertain cases go to clarification or deeper investigation.

Use a configurable inexpensive model initially, and evaluate its decisions on real incoming issues. It shouldn’t decide architecture or launch coding directly. Planning is a separate step; Codex/OpenCode starts once there’s a scoped brief and execution authority.

Exchange 3

User prompt

where do humans plug in?

Final agent response

In this proposal, humans plug in at three points:

Before coding: Neon triages and drafts a scoped brief. You resolve ambiguity, adjust scope or design, and release it into the queue. Small tasks could later skip this gate under an explicit policy.
When judgment is needed: Neon pauses for missing requirements, material scope changes, exhausted repair attempts, or uncertain execution state. You clarify, redirect, retry, or cancel.
Before merge: Neon presents the PR, verification evidence, and unresolved decisions in the existing review workbench. You review, request changes, or merge.

You also configure the standing rules: eligible repos, coding harness, budgets, and publication permissions.

You shouldn’t have to relay messages between phases or approve every tool call. Once you release a brief, the factory carries it through implementation, verification, bounded repairs, and draft-PR creation within that authority.

Exchange 4

User prompt

>Before coding: Neon triages and drafts a scoped brief. You resolve ambiguity, adjust scope or design, and release it into the queue. Small tasks could later skip this gate under an explicit policy.

But surely this should be happening with the help of a model ? Like a model proposing plans and sharing briefs and then itterating on it with a human ?

Final agent response

Yes—that should be an interactive planning session with Neon, not a form you fill out or a finished brief you merely approve. My wording undersold that.

The intended flow:

Small triage model classifies the input and identifies missing context.
Planning model investigates the repo, proposes a brief and approach, surfaces tradeoffs, and asks focused questions.
You and the planner iterate in a persistent conversation. Neon updates the brief, acceptance criteria, and proposed implementation as decisions settle. For UI work, that can include mocks; for architecture, diagrams and interface sketches.
You release the agreed plan, and Neon packages that context for Codex/OpenCode.

The conversation and versioned brief stay attached to the work item. If implementation uncovers a consequential assumption, it comes back to that planning conversation with a concrete finding and proposed revision.

So the human supplies judgment and direction; the model does the investigation, drafting, and revision work.

Exchange 5

User prompt

and thats all clearly covered in your html doc ?

Final agent response

It wasn’t clear enough. I’ve updated the HTML proposal with a dedicated “Humans plan with Neon” section covering:

Lightweight triage → separate planning model.
Persistent conversation with iterative briefs, plans, mocks, and decisions.
Human release of an agreed version.
Codex/OpenCode handoff.
Significant implementation discoveries returning to that planning conversation.

The state model, UI proposal, and implementation slices now reflect this too. Refresh the open page to see it.

Exchange 6

User prompt

ok we should make sure we clearly call out human touch points.

Final agent response

Updated the proposal with a Human touchpoints section covering:

Setup and standing policy.
Collaborative planning with Neon.
Required plan release.
Conditional interventions when blocked.
Human review and merge.
Learning and cleanup decisions.

Each identifies what Neon presents, what the human decides, and what proceeds automatically. Refresh the page to see it.

Exchange 7

User prompt

Ok, are we pushing info/status/context back into the Github Issues ? Should we even ?

For shaping the tasks, how do you plan to let users interact/review things. We already have a diff viewer we can use, a briefing surface, we can also do things like render markdown proposals etc.

Final agent response

Yes, we should write back to GitHub issues, selectively. I recommend an opt-in, maintained Neon comment containing:

Current status and next action.
Agreed scope and acceptance summary.
Any actionable blocker.
PR link and final outcome.

Update it on meaningful transitions. Keep full planning conversations and logs in Neon. Explicit questions can be posted separately; replies feed the planning conversation, without automatically changing the approved scope or authority.

For shaping, use the surfaces we already have:

Briefing: problem, proposed approach, unresolved decisions, and next action.
Planning workbench: persistent Neon chat alongside rendered Markdown proposals.
Diff viewer: compare proposal versions and inspect referenced code.
Contextual discussion: select a passage or file and ask Neon to explain or revise it.
Release: review the current plan and authorize that specific version.

Mocks and diagrams become attached planning artifacts. The main additions are durable proposal versions, discussion anchors, and release semantics. The existing review contracts are Git-oriented, so those need extending.

I’ve added both policies and a layout sketch to the HTML proposal.

Exchange 8

User prompt

ok lets get this plan commited. Before we begin implementation. What do you need ? ssh keys ?

Final agent response

Committed as 403a70dc on agent/software-factory-plan. Working tree is clean; formatting and secret scan passed. Not pushed.

No credentials needed to start implementation. For deployment and live testing, we’ll need:

exe.dev VM hostname and SSH access. Existing access through your SSH agent is ideal. Otherwise provide the local key-file path and username; don’t paste a private key.
A test GitHub repository with permission to configure webhooks and create branches, issues/comments, and PRs.
Coding harness authentication on the VM. I’d start with Codex, then add OpenCode. We can configure login during setup.
Any repository-specific setup/test configuration, when needed.

We’ll generate the webhook signing secret during setup. VM creation/deletion credentials can wait until the remote-worker phase.

For now, the VM hostname is enough to establish the next deployment step.

Exchange 9

User prompt

The vm instance we'll use is [REDACTED] , note that this repo is public - so do not check in credentials/hostnames/etc. There should also be a secrets scanner as a pre-commit hook. Do not by pass it.

Final agent response

Created the slice 1 implementation plan and handoff, linked from the roadmap and HTML proposal.

Five stacked PRs cover:

Manual intake and durable state
Model triage and planning
Human shaping and release
GitHub ingress
GitHub status and discussion

The handoff assigns implementation to separate agents, with me managing dependencies and reviewing changes. Slice 1 stops before coding execution.

Formatting, links and secrets scan passed. No deployment details included. Implementation has not started; these changes remain uncommitted.

Exchange 10

User prompt

Ok you act as orchestrator and manager delegating implementation to sub agents, we should produce no pr's until dedicated sub agents performing static reviews come back with no findings.

You should act as final reviewer focusing implemenation and product plan adherence. Ensure that implementors include screenshots where applicable (gh now supports uploading images). Spawn subagents with lower reasoning levels as you set fit (e.g. medium for reviewers , low for implementers, whatever).

Final agent response

I need four things:

SSH access: confirm your existing SSH agent/config can connect to the VM, and provide the SSH username or local alias. Don’t send private keys.
Model configuration: which provider/model should handle triage and shaping? Credentials should already be installed privately, or you can configure them directly on the VM.
GitHub test target: a repo and disposable issue we can use. We’ll need permission to configure its webhook and credentials with the necessary issue/comment access.
**Test authorization:[REDACTED] permission to deploy/start Neon on the VM, restart it during recovery tests, and post/update factory comments on the selected issue.

With those, I can handle setup and testing. I’ll bring you into the shaping conversation to revise the model’s brief and explicitly release the test task—the key human interaction we need to validate.