Governed Codex Automation Planning Index

Purpose

This folder records the product, architecture, security, distribution, and adoption direction for evolving the internal label-driven Codex workflow into a reusable consulting accelerator.

The material is planning guidance only. It does not authorize implementation, client installation, credential sharing, or operation of a hosted service.

Current direction

Client-sharing plan

Status: working direction — not approved for implementation.

This plan proposes a versioned, self-managed orchestrator release that clients can fork and provision in AWS accounts they control, with:

• A centrally tested but client-forkable application and Terraform stack.
• Client-owned infrastructure, state, deployment identity, GitHub App, credentials, adapters, and declarative policy.
• A documented bootstrap, protected plan/apply, verification, upgrade, recovery, and teardown path tested from a clean synthetic fork.
• Separation between untrusted generation and trusted publishing.
• Immutable release pins and reviewable upgrades.
• A consulting-led adoption path beginning with synthetic dry runs and a limited pilot.

The plan deliberately excludes distributing implementation from this meta repository and defers any consultancy-operated, multi-client control plane until it has a separate threat model and operating design.

Client repository provisioning plan

Status: working direction — not approved for implementation.

This plan defines the repository-level adoption path after a client provisions its orchestrator: a client-owned Node.js and TypeScript template, an idempotent provisioner with non-mutating drift checks, strict adapter registration, GitHub-plan-aware governance, and a synthetic readiness test that stops at human review.

Autonomous goal-to-deployment delivery pipeline

Status: approved long-term direction.

This plan evolves the current issue-level workflow toward governed decomposition of business goals into milestones, epics, issues, plans, builds, and pull requests. It keeps GitHub as the system of record, introduces a durable state machine behind label projections, preserves human milestone checkpoints, and keeps LangGraph replaceable behind an orchestrator interface.

Governed AI sprint delivery orchestrator implementation plan

Status: approved implementation direction — implementation active.

This is the recommended implementation starting point. It defines the private ai-delivery-orchestrator repository, AWS Fargate and Aurora Serverless v2 deployment, LangGraph runtime, GitHub App callbacks, secured Bruno API, explicit issue-list workflow, dependency-aware scheduling, risk-based plan approval, automated pull request review and repair, and a frozen, human-authorized portal backlog run with guarded automatic merge.

The 2026-08-07 MVP definition and backlog checkpoint supersedes the earlier human-merge pilot boundary. MVP is now an AWS-hosted, fully traced run through a frozen and human-authorized client-portal Phase 1 manifest, with separated builder/reviewer/merger identities, enforced branch protection, independent automated review, bounded repair, and guarded squash auto-merge. Five linked GitHub milestones decompose the remaining work into epic trackers and independently planned child issues.

The 2026-08-17 M2 runtime and operator control checkpoint records all M2 milestones as complete: durable infrastructure (Epic E1 #46 closed), ingress and operator control (Epic E2 #47), and safe operations (Epic E3 #48), with live deployment validation in AWS (successful protected apply and destroy runs). M3 live planning and execution is now the next ordered milestone.

The 2026-08-10 M1 completion checkpoint records all M1 safeguards as complete: immutable run authority, public/protected portal controls, and independently attributable reviewer/merger identities with live exact-head attribution and rotation evidence. No automated review or merge runtime is enabled. M2 AWS runtime and operator control is now the next ordered milestone.

The 2026-08-09 delivery progress checkpoint is the preceding checkpoint that records M1 Epic E1 and client-portal Epic E2 completion before identity provisioning.

The 2026-08-01 implementation checkpoint records the merged domain, PostgreSQL persistence, orchestration primitives, secure webhook-intake, provider-stub, and operating-runbook slices, along with the unapplied Terraform state/OIDC/ECR/network foundation, current validation evidence, and explicitly pending work.

Sprint delivery orchestrator cost estimate

Status: planning estimate as of 2026-08-02 — validate before deployment.

This companion estimate translates the implementation architecture into weekly AWS operating ranges for idle, light, typical, and heavy sprint use. It documents workload assumptions, separates excluded OpenAI and GitHub costs, identifies Aurora wake time and CloudWatch logging as the main AWS cost risks, and defines measurement and budget controls for the pilot.

OpenAI usage attribution and project strategy

Status: approved architecture guidance for the governed delivery pilot.

This companion decision keeps centralized OpenAI organization reporting while allocating planning, implementation, repair, and independent review usage to the target application’s OpenAI project. It defines stage-specific credentials, trusted project routing, bounded request metadata, application-owned telemetry, monthly reconciliation, and the rule that deterministic approval and merge do not normally require model calls.

Recommended reading path

For packaging and client adoption, read the client-sharing plan, followed by the client repository provisioning plan. For evolution of the internal delivery workflow, read the goal-to-deployment pipeline, then use the sprint delivery orchestrator implementation plan for the first build sequence and its cost estimate for the pilot budget assumptions. Use the OpenAI usage attribution strategy when implementing live model credentials, routing, telemetry, or cost reporting.

Before proposing implementation, pay particular attention to:

1. The client-owned adapter, repository-provisioning, and credential model.
2. The security boundary between generation, validation, and publishing.
3. Distribution and legal-readiness requirements.
4. The phased portability and client-pilot acceptance plan.
5. The immutable human authorization gate for the MVP manifest, separated automatic-review/merge identities, and continued human control of release and deployment.

Current next step

For client sharing, complete the internal pilot and the dedicated repository’s licensing and distribution readiness, then prove self-provisioning from a clean synthetic fork in a fresh AWS test account. A second operator must be able to follow the published bootstrap, deployment, verification, upgrade, recovery, and teardown guidance without consultancy-owned infrastructure or undocumented intervention. Then use the client repository provisioning plan to prove clean node-v1 target creation, idempotent configuration, non-mutating drift checks, and a synthetic draft-pull-request readiness path.

For goal-to-deployment automation, continue the approved sprint delivery orchestrator implementation plan from its latest MVP checkpoint. Start with that definition and its linked M1-M5 GitHub hierarchy. Complete authority/repository safeguards, the AWS runtime, live orchestration, independent review/repair/merge, and readiness in sequence before freezing and authorizing the portal manifest.

Maintenance

Keep this index synchronized whenever a document in this folder is added, removed, renamed, superseded, or materially changes purpose or status. Clearly distinguish approved current guidance from proposals and historical material.