# Factory Project Operations Context ## Purpose and scope This file is the authoritative operating context for AI agents that manage **our projects**. It does not replace repository-level `AGENTS.md`, source control, service documentation, or Paseo agent/workspace records. An **our project** is a cross-server product or system. Its definition file lives at `factory/.md`. A native Paseo project is a local execution unit: one repository or directory on one daemon host. ```text Our project → server-local Paseo project → workspace → agent → active session ``` ## Start every task with the project definition 1. Identify the project key and read `factory/.md`. 2. Identify affected servers, repositories, services, and target devices. 3. Read the repository's nearest `AGENTS.md` before inspecting or changing source. 4. Check the target host's actual Paseo/provider/workspace state; do not infer it from this brain record. 5. Create a concise task record: goal, acceptance criteria, allowed paths/commands, required checks, forbidden effects, evidence, and approval gate. ## Operating policy - **Bounded goal loops.** After discovery and an approved plan, the factory may iterate isolated implementation → deterministic verification → independent review → targeted repair until the named acceptance criteria pass. Every loop must have an iteration cap, wall-clock/resource cap, and clear stop conditions. It must stop and report at approval boundaries or when blocked; it may never self-approve merge, push, deployment, restart, publishing, credentials, migrations, or production configuration. - **Exclusive factory ownership.** For every factory-managed project task, the `factory` profile alone performs repository/server inspection, Paseo dispatch/monitoring, edits, commits, pushes, deployments, and verification. The default/personal profile is the human-facing control surface only: it relays instructions and reports factory evidence but never executes project work directly. - **Coordinator dispatch-and-follow-through.** For multi-step work, do not call the factory profile as a one-shot `-z` process. Keep the named coordinator session interactive/resumable; record every dispatched Paseo agent/workspace ID, monitor its state, then resume that same coordinator session with the observed result. A pinned session is historical continuity only, not a background supervisor. Use an explicit bounded monitor/continuation when work must outlive the coordinator turn. - **Paseo session permission mode.** Every new coding or release Paseo agent must be started explicitly in the provider's `auto-review` mode; for Codex, pass `--mode auto-review`. Do not rely on defaults, fall back to full-access/unreviewed modes, or continue if the requested mode is unavailable. - **One durable coordinator session per feature or incident.** Resume the same factory-profile session for all follow-ups to a project feature, release, reconciliation, or incident. Do not create a new one-shot coordinator session for every request. Name it `: ` and record its ID in the project definition when continuity matters. - Our project files are the cross-server project-manager record; Paseo Desktop/Web are execution views, not the project authority. - One source-changing task uses one isolated worktree workspace. Do not have independent agents edit a shared checkout. - Planner and reviewer are read-only. Implementers may edit only their assigned worktree. - Verifiers report exact command outcomes; they do not silently repair source. - Merge, deploy, restart, publish, external sends, credentials, production configuration, and migrations require explicit human approval. - A Paseo status change may create a notification or review task; it never authorizes a production action. - Never place credentials, pairing offers, raw private audio, or user data in these project files. ## Durable evidence to record Record stable decision and handoff data only: repository/host mapping, workspace/agent IDs when needed for continuation, verification outcomes, approval decisions, rollout/rollback notes, and open blockers. Keep raw logs and transient agent conversation out of the brain. ## Project-definition standard Each `factory/.md` includes purpose, server/repository/service mapping, factory readiness, persona roles, special constraints, current open work, and human approval boundaries. ## Updating this directory - Create a new definition before treating a system as a factory-managed project. - Update an existing definition when its server/repository/service mapping or safety boundary changes. - Do not claim a remote host is enrolled or a deployment works without current host evidence. - Keep definitions concise and link to detailed project notes instead of duplicating them.