Operating Model

Core Idea

Prox OS is becoming an AI-readable product system, not only a code repository. The repository should preserve the founder's intent, system boundaries, task graph, quality gates, and release decisions so humans and AI agents can act without relying on one long chat transcript.

Natural language is the interface. Repository docs are the context substrate. Code is one generated and verified artifact among others.

Software 3.0 Posture

Prox OS treats natural language as a programming interface, but not as a replacement for engineering judgment. The repo docs carry the durable context, task graphs define execution boundaries, quality gates verify the generated artifacts, and humans keep final product judgment.

This is the practical Software 3.0 stance for this repo:

• Prompts become specs, RFCs, ADRs, task graphs, and run logs.
• Code is generated, reviewed, tested, and integrated as an artifact.
• Context engineering is a first-class engineering activity.
• Architecture boundaries stay white-box even when implementation details are increasingly AI-produced.

Founder Role

The founder remains responsible for:

• Product judgment.
• Architecture boundaries.
• Context engineering.
• Task decomposition.
• Scope control.
• Cost strategy.
• Final merge and deploy judgment.

This is the AI-native solo builder model: the founder is less "the person who writes every line" and more "the person who runs a small AI engineering factory with white-box architecture and reviewable artifacts."

Control Layers

Feedforward And Feedback Controls

Thoughtworks Technology Radar Vol.34 describes codebase cognitive debt as the gap between implementation and shared understanding. Prox OS should treat that as a first-class risk for AI-assisted development.

Feedforward controls:

• Agent scopes.
• Spec-driven development.
• Required reading.
• Allowed paths and forbidden paths.
• Task graphs.
• Context engineering.
• RFC/ADR gates.

Feedback controls:

• Typecheck, lint, architecture checks, and CJK checks.
• Storybook and UI Workshop review.
• Browser preview for layout-sensitive work.
• CI and future mutation testing.
• Integration reports.
• Release-plan closure.

Personal Platform Engineering

This control plane is a personal version of platform engineering:

• Golden paths for feature, fix, docs, refactor, business, and growth work.
• Standard templates for tasks, decisions, reports, and runs.
• Scope and quality gates for opt-in governance work.
• Reusable prompt patterns for different tools.
• A way to turn consciousness-flow input into executable work.

Future Control-plane Repo

Monorepo phase:

• docs/development/ai-control-plane/ is the orchestration source of truth.
• Existing repo docs remain canonical for architecture, roadmap, design, and product details.

Multi-repo phase:

• A separate control-plane repo may own:
  • Global app registry schema.
  • App contract index.
  • Cross-repo task graphs.
  • Release plans.
  • Integration reports.
  • projects.yaml.
  • agents.yaml.
  • Prompt templates.
  • ADR/RFC indexes.
  • Cost model.
  • Run logs.
• Architect AI reads the control plane first, then assigns scoped work to the correct repo and worker.

Non-goals

• No automatic agent scheduler is implemented by this documentation.
• No CI, deployment, billing, auth, database, or MCP behavior is changed here.
• No agent should treat these docs as permission to bypass AGENTS.md.