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.

Our project → server-local Paseo project → workspace → agent → active session

Start every task with the project definition

Identify the project key and read factory/<project-key>.md.
Identify affected servers, repositories, services, and target devices.
Read the repository's nearest AGENTS.md before inspecting or changing source.
Check the target host's actual Paseo/provider/workspace state; do not infer it from this brain record.
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.

4.8 KiB Raw Blame History