Skip to content

Request Operations Policy

  • Status: CURRENT INTAKE BOUNDARY / HISTORICAL P3-B DECISION INPUT
  • Owns: Request definition, current intake principles, separation from Codex session, Phase Task, incident and deployment authority
  • Does not own: live Request rows/status, Registry store/service/API topology, Control Tower Codex client implementation, Phase/Task status or incident steps
  • Update when: current intake/incident boundaries or successor decisions change; former P3 sequencing remains historical
  • Related sources:
  • Control Tower boundary
  • Durable Context Appendix J
  • Approval: P1-001 D4=A, 2026-07-30; P3 sequencing corrected 2026-08-03; P3 collaboration contract corrected 2026-08-05

Current Scope

The root P1–P12 programme closed on 2026-08-14. The P3-A/P3-B order and the collaboration design below are the decision inputs of that time and do not prove the current start order, the session implementation or the authority. A current request is classified through Agent Workflow; the work scope, state, verification and handoff follow the New-System Task and git, and the phase order and exit conditions follow the New-System Roadmap. This document preserves the boundary between a Request and execution or deployment authority, and does not approve a separate Registry implementation.

Definitions And Authority

  • Request: a problem, change, investigation or operational need submitted by a developer, Codex, field user, system or incident source.
  • Codex session: an AI coding conversation/thread and its execution evidence. A session can be a Request source reference but is not itself a Request Registry row or lifecycle authority.
  • Phase Task: a repository execution unit. The exact current New-System Task and Git own its scope, status and evidence; the New-System Roadmap owns phase order and exit gates. Root P1–P12 Tasks are historical.
  • HTTP requestId, source session/message ID, incident ID, future Request ID and Phase Task ID are distinct and are never automatically equivalent.

Receipt of a Request or existence of a Codex session does not automatically change Product scope, Task status, approval, completion or external-effect authority. An explicit current user request is reconciled through Agent Workflow; stale P3 sequencing cannot veto it.

CTC Codex Session Collaboration Boundary

The former P3-A plan proposed first improving the Control Tower /codex client around the canonical Linux CTC checkout and Codex session store. The proposed surface covered simple shared-session visibility, continuation, stop, plan-first interaction, reconnect and audit without creating a separate Workspace product, route or API namespace.

The session policy recorded for that former pilot was:

  • admin and jaylee create team sessions that both staff accounts and superadmin can continue;
  • superadmin creates private sessions that staff cannot discover;
  • there is no per-session share/revoke, owner transfer, controller takeover or branch/fork workflow.

The former /codex design targeted non-developer clarity and hidden internal runtime metadata by default. It is not a generic Request Registry, Task manager, GitHub delivery controller or CTC business authority.

The former plan placed generic Request Operations in the later P3-B lane (P3-007~009) after the Codex collaboration pilot. This history does not reactivate that lane or select Orca, Control Tower, or another current implementation target.

Current Intake Policy

Until an explicit current decision approves a Registry and adapters:

  1. Preserve the source session/event/message and necessary evidence in its current owner.
  2. Check for duplicate or existing Phase work without claiming a generic dedup service exists.
  3. Do not decompose one Request into a persisted Task graph or automatically create, progress, approve, complete or deploy a Task.
  4. Intake alone does not change Product/Roadmap authority. Reconcile an explicit current user instruction in the exact owning scope through Agent Workflow.
  5. Route reusable contracts, cross-module dependencies, incidents and promotion needs to the owning document and user review.
  6. External writes, Git, promotion, deployment and incident effects require their separate Project Operations/runbook authority.
  7. Do not copy secrets, credentials or protected raw content into general documents, logs or summaries.

Current Channel Boundary

Developer/direct, Codex, field/operator, monitoring and incident/correction sources remain distinct evidence surfaces.

No channel, repository, database, Markdown file, GitHub surface or Codex session store becomes a generic Request Registry by assumption. Current New-System Task documents and Git still own their execution status; Request intake and Task status are distinct.

Control Tower's operational boundary and CTC Codex collaboration boundary are owned separately. CTC business operation must not gain a request-time Control Tower dependency.

P3-B Open Decisions

The former P3-B plan left the following questions unresolved. They require a current successor decision, not reactivation of P3:

  • versioned Request envelope/event, provenance, privacy and redaction;
  • duplicate/related/supersedes, triage, routing, status, audit and retention;
  • storage, service, API, implementation repository and topology;
  • developer/Codex/field/system adapters and CTC routing metadata;
  • bounded work, existing Phase Task, promotion review and incident relation.

This policy selects none of those options and claims no current Registry implementation.

Prohibited Assumptions

  • restoring a single REQUESTS.md live queue or manual REQ-xxx numbering;
  • restoring old Control Tower Task/Program/Feature/session binding or GitHub Project as Request authority;
  • treating the Control Tower Codex client or ~/.codex as the Request Registry;
  • assuming a CTC operational DB, Control Tower store, GitHub or session store is the default Registry;
  • coupling intake to Task generation, status progression, release Gate or deployment;
  • presenting stale, fixture or historical evidence as current Request state;
  • making CTC local operation depend on Control Tower availability.

Source: docs/REQUEST_OPERATIONS.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged. A user instruction quoted inside the text is kept in its original language.