Skip to content

Control Tower Boundary

  • Status: CURRENT BOUNDARY / P3 OWNER
  • Owns: the relationship between CTC Runtime and the Control Tower operational core, the existing /codex CTC collaboration consumption boundary, and the P3 cross-repository implementation rule
  • Does not own: generic Request Registry topology, CTC Phase/Task status, Control Tower implementation detail or live host status
  • Update when: Control Tower current source, CTC consumption contract or P3 authority decision changes
  • Related sources:
  • Context Appendix J
  • sibling repository kylejang1/control-tower

1. Control Tower Core

Control Tower core is the Hub operational control plane. It owns:

  • tenant/deployment registry;
  • runtime configuration publish and effective-state observation;
  • service/runtime health and inspection;
  • operational access and audit;
  • bounded deployment operation and verification;
  • Server Admin migration candidates.

CTC business request and job do not depend on request-time Control Tower lookup. Runtime continues from local DB/env or approved local snapshot.

2. Existing /codex CTC Collaboration Surface

P3 improves the existing Control Tower /codex surface for CTC only.

projectKey = ctc
cwd = /home/kyle/workspace/ctc
CODEX_HOME = /home/kyle/.codex
accounts = superadmin, admin, jaylee

The existing /codex surface may list, read, create, resume, continue, stop and audit CTC Codex sessions according to P3-004. It is not a Task manager, Request Registry, GitHub delivery owner, deployment Gate or CTC business authority.

Mac ChatGPT.app, Linux CLI and Control Tower web are clients of the same Linux Codex environment. An unofficial Linux ChatGPT app remains optional owner-only comparison, not a product dependency. Official Codex CLI and codex app-server are modes of the same installation.

The web/API exposes no project, repository, host or path selector. Multi-project support and generalized project ACL are not current scope. A dedicated Linux user/container/separate checkout or separate CODEX_HOME is not a current prerequisite and may be reconsidered only from later evidence and explicit approval.

No separate ctc-workspace product, route, API namespace, service, database or session store is introduced.

3. Account And Session Boundary

Current application accounts are exactly:

  • superadmin;
  • admin;
  • jaylee.

Session visibility is fixed at creation:

  • admin and jaylee create team sessions. Both staff accounts and superadmin can list, read and continue them.
  • superadmin creates superadmin-private sessions. Staff must not discover them through list, search, detail or mutation APIs.
  • A team session remains team-visible when superadmin contributes.
  • Creator attribution is immutable.
  • Legacy sessions with unknown creator default to private until bounded classification.

The backend enforces this policy. UI filtering alone is insufficient.

There is no per-session share/revoke editor, owner transfer, controller takeover UI or generalized Codex role/project matrix. A session has one active turn and no unbounded prompt queue. A retained pending follow-up is limited to one visible replaceable item.

4. Non-Developer Interaction Boundary

The current goal is not ChatGPT feature parity. The default UI optimizes for a non-developer who needs to find a shared session, see a simple state, add a follow-up, optionally approve a plan and read a concise result.

Required direction:

  • one focused session is the default;
  • list rows show title, creator, simple status and last activity only;
  • long-running active work has no arbitrary overall timeout;
  • inactivity and connection loss show a clear recovery action instead of an endless spinner;
  • retries and reconnects resume the same turn and are idempotent;
  • duplicate transcript/progress/error/final text is coalesced;
  • internal IDs, model/token/runtime, branch/worktree, raw tool/event and subagent detail are hidden by default;
  • technical paths, commands, logs, tests and diff are collapsed under details;
  • plan first is read-only until proceed as planned; after that, implementation continues in the same session;
  • plan-first does not create a conversation fork, Git branch or worktree.

5. Legacy And Retired Surfaces

  • Existing /codex route, session/transcript/attachment bytes and supported adapters are preserved and improved in place.
  • Managed Task, Program, Feature, session binding, hosted development governance and task-coupled deploy remain retired.
  • Orca is excluded from the current target architecture and P3 implementation. Existing Orca source/routes/services are cleanup candidates only after historical evidence and caller-zero review.
  • Control Tower repository does not retain a duplicate active product plan for CTC Codex collaboration; CTC Context/Roadmap/P3 Tasks are canonical.
  • Existing split/multi-pane, explicit share, takeover, fork and other excluded UI/code may be removed or hidden after caller and regression review; they are not product requirements merely because source exists.

6. Repository Ownership

  • CTC repository owns Product, durable Context, Roadmap/P3 Tasks, repository rules and acceptance scenarios.
  • Control Tower repository owns operational core source and the approved existing /codex implementation.
  • Codex session IDs never become CTC Phase Task IDs, Request IDs or deployment approvals.
  • Control Tower changes that alter the CTC Codex collaboration contract update both repositories' owning documents in the same cross-repository work.

7. Request Operations

Generic Request Operations are the later P3-B lane. The CTC /codex collaboration surface is a source/interaction surface, not the Registry. Request policy is owned by docs/REQUEST_OPERATIONS.md.

8. Prohibited

  • CTC business operation request-time dependency on Control Tower;
  • old Task/Program/Feature/session-binding restoration;
  • multi-project surface or user-entered project/repository/path/host target;
  • separate Workspace product/route/API/service/session authority;
  • explicit sharing/owner/controller framework beyond the fixed team/private contract;
  • conversation branch/fork or automatic Git branch/worktree as a staff workflow;
  • automatic Task creation, status progression, Git action, release Gate or deployment from a session;
  • treating Control DB/session metadata as Runtime effective state;
  • raw credential or secret exposure;
  • unapproved Production, DB, provider or service mutation.

Source: .agents/rules/CONTROL_TOWER.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.