Prox OS Internal Docs
DevelopmentAIProtocols

AI Execution Protocol

Define execution modes for AI-assisted work in the Prox OS monorepo.

Purpose

Define execution modes for AI-assisted work in the Prox OS monorepo. AGENTS.md remains the strong rule source.

Default mode is Direct Implementation Mode. RFC, ADR, slicing, phase planning, and proceed-gated workflows are manual opt-in only.

Large task size alone is not enough to trigger Slicing Mode.

Mode 1: Direct Implementation Mode

Default. Use for ordinary development, documentation updates, small-to-medium UI work, copywriting, routes, app registry display updates, Storybook, local mock data, and non-destructive refactors.

Rules:

  • Read only the minimum relevant context.
  • Implement in the same run.
  • Do not stop after planning.
  • Do not ask the user to type "proceed".
  • Do not create an RFC or ADR.
  • Summarize files changed and checks run after implementation.

Mode 2: UI Incubation Mode

Use for broad visible product-surface work such as Founder Suite apps, Join Us, Hola, Pricing, App Store mock surfaces, placeholder app grids, app cards, and prototype route surfaces.

Rules:

  • Visible UI progress is primary.
  • Use roughly 80% implementation, 15% docs sync, 5% planning.
  • If internal phases are useful, Phase 1 must produce visible UI/code.
  • Do not proceed-gate unless the user explicitly asked for staged confirmation.
  • Keep mock/static data clearly labeled as prototype or internal alpha when appropriate.

Mode 3: Productization Mode

Use when deepening an already-incubated top app into a more durable product surface.

Rules:

  • Add moderate docs, acceptance criteria, tests, Storybook stories, or visual QA where useful.
  • Still do not start RFC, ADR, slicing, or proceed gates by default.
  • Recommend Opt-in Slicing Mode only if the work touches high-risk boundaries.

Mode 4: Opt-in Slicing Mode

Manual opt-in only. Do not load or apply this mode by default.

Enter only when the user explicitly says things like:

  • "start slicing mode" or the same request in the user's language;
  • "start RFC-style development" or the same request in the user's language;
  • "write an RFC first";
  • "write an ADR first";
  • "RFC first";
  • "ADR first";
  • "phase plan only";
  • "planning only, do not change code";
  • "do not change code";
  • "proceed-gated";
  • "wait for my confirmation between phases";

When activated, announce it at the beginning of the response so the user can interrupt early if it was unintended.

Rules:

  • RFC, ADR, slicing, and proceed gates are allowed.
  • Planning docs should be short.
  • Phase 1 means the first visible implementation slice unless the user requested planning-only.
  • Do not use this mode for ordinary UI incubation, local mock UI, docs index cleanup, lightweight roadmap sync, Storybook stories, copywriting, app registry display updates, or non-destructive refactors.

High-risk Work

If the task looks high-risk but the user did not opt in, recommend Opt-in Slicing Mode but keep working in Direct Implementation Mode unless the user confirms.

High-risk areas include:

  • auth, login, sessions;
  • permissions and security;
  • payment, Stripe, live billing, entitlements;
  • database schema or migration;
  • API contracts;
  • Cloudflare deploy pipeline;
  • app runtime protocol;
  • microfrontend isolation;
  • production data migration;
  • destructive refactors or deleting large code areas;
  • multi-user collaboration contracts;
  • legal/compliance flows with irreversible assumptions.

Planning Budgets

  • Preflight plan: max 30 lines.
  • Slice plan: max 250 lines.
  • RFC / ADR: target 300-500 lines.
  • If an RFC exceeds 500 lines, split it into a main decision doc plus appendix.
  • Phase 1 must not be another long planning document unless the user explicitly requested planning-only.

Proceed Gates

Proceed gates are off by default.

Allowed only when:

  • the user explicitly requests Opt-in Slicing Mode or staged confirmations;
  • the task involves auth, payment, security, database, or destructive migration;
  • missing user information truly blocks safe implementation.

When using a proceed gate, explain why. Otherwise implement and summarize.

Scope Expansion

Direct Implementation Mode still requires discipline. If implementation reveals that the requested change would become unsafe, destructive, or materially broader than the user asked for, stop and explain:

Scope expansion detected.
Reason:
New required scope:
Recommended safe next step:

Do not turn this into automatic slicing; ask whether the user wants Opt-in Slicing Mode.

Verify And Docs Sync

Verification and docs sync can be used without Opt-in Slicing Mode:

  • Run relevant checks such as pnpm typecheck, pnpm lint, pnpm arch:check, pnpm check:cjk, targeted builds, or app-specific tests.
  • Fix blocking errors introduced by the current change.
  • Update only docs tied to the implemented change.
  • Run pnpm docs:sync when the docs site must reflect root docs/** changes.

On this page