brain backup 2026-09-14

projects/FACTORY_OPERATIONS.md

@@ -0,0 +1,49 @@
+# 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/<project-key>.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/<project-key>.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 `<project-key>: <feature-or-incident>` 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/<project-key>.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.