Factory

A campaign is the saved record of one software goal. Telegram approval uses the campaign's own button or scoped command, so the system can identify exactly which job Emre approved. Installing or starting the services does not activate a proposal. Model-generated feedback cannot create owner approval. This example includes local integration in its approved scope; publishing remains a separate decision.

Factory starts fresh lead sessions with project instructions, a compact working map, and relevant new evidence. The map explains what is known and what to do next; it can change as the work reveals facts. Sol through Codex or Opus through Droid supplies the lead. Straightforward work goes directly to implementation. An important factual uncertainty can receive a small research step first, normally assessed by the lead without a separate reviewer. The execution adapter checks subscription access and applicable quota; unavailable capacity leaves work waiting.

Git calls the separate working copy a worktree. Factory creates a branch for the step and preserves relevant non-private unfinished source work in the starting baseline without resetting the original copy. The eventual delivery must include the campaign's changes rather than unrelated baseline work. Worker reports include surprises and dead ends. Factory checks declared private-file changes after the run and discards a candidate if it detects them. This detects changes, not silent reads. A successful process exit alone does not show that the export is correct.

Factory rejects a builder and reviewer using the same underlying model. Review starts after the builder and can examine partial work even if the builder run failed. The reviewer is instructed to exercise the requested behavior before relying on the builder's explanation and derive expected results from the contract and source data. Changes needing a new design or unrequested dependency return to the lead. A finished review is process evidence; the lead still owns judgment against the full goal.

Worker results wake a fresh lead session. The original owner goal stays authoritative through revisions. Independent steps can run in parallel; within one build step, review follows the builder. A step needing an unresolved decision waits while independent work can continue. The lead rechecks private-file changes before integration and includes only intended campaign changes. Local integration is permitted in this example; public release is not. Delivered commits carry a campaign reference. Recording completion does not deploy the product or guarantee acceptance.

Hermes selects relevant reports, changes, text outputs, and images. It has no terminal or editor, so the lead must obtain missing observations. Its silent engineering feedback returns to the same approved campaign, remains separate from owner input, and grants no new permission. Genuine product direction, taste, access, or authorization decisions can reach Emre. With preview setup separately approved, Hermes can include a protected link to a selected evidence file or static demo. The link requires the configured owner's email sign-in, expires within two hours, and depends on the host staying online; it is not a production release.

The delivery record connects the goal to the campaign's commits and completion reports. Hermes relays the owner's original score and words; it does not infer a rating from apparent satisfaction. Each rating schedules a retrospective, a look back through the campaign's prompts, reports, timing, and execution evidence. It may propose a focused Factory improvement but cannot activate a new campaign itself. Whether this mechanism measurably improves future deliveries remains unproven.