Skip to content

Realign docs around Codex CLI fork plus Every Code overlays #395

@shiny-code-bot

Description

@shiny-code-bot

Finish Line

Repo guidance, metadata, and migration docs consistently say this repository is a Codex CLI fork with selected Every Code overlays, not an Every Code product-direction workspace with Codex underneath.

Current Status

State: New follow-up created from the 2026-06-06 planning realignment.

Why this exists:

Current direction:

  • Every Code is moving into maintenance mode as a standalone product direction.
  • The repo should behave as a Codex CLI fork by default.
  • Every Code features should be layered only when they are selected as required overlays and validated.

Spike cleanup note:

  • spike/codex-base-port was reviewed on 2026-06-06. It is clean, ahead 1/behind main, and served as historical proof of the Codex-base workspace.
  • Current origin/main already absorbed the real substrate migration via docs: record Codex substrate migration policy #389/feat: replace Rust substrate with Codex base #390 and later follow-ups.
  • Most fixture/test candidates from the spike are already present on current main. The only notable leftover candidate was an ignored resize_reflow mock-server style, not urgent fixture data.
  • Keeping the spike worktree risks future confusion; it can be deleted after this durable note.

Acceptance Criteria

  • Update AGENTS/repo guidance so future agents see Codex CLI fork compatibility as the default and Every Code overlays as explicit exceptions.
  • Update .github/github.json workflow metadata to match the fork-plus-overlay direction.
  • Update docs/upstream-import-policy.md so upstream roles, naming, and fork/substrate policy do not imply new broad Every Code product divergence.
  • Update docs/codex-base-feature-inventory.md or successor docs to classify features as Codex compatibility, required Every Code overlay, deferred, retired, or replaced-by-Codex.
  • Make the relationship to openai/codex, just-every/code, code-rs, and codex-rs clear enough that future imports do not leak the old direction back in.
  • End with the repo-required ./build-fast.sh validation if the implementation branch changes tracked repo files.

Relationships

Metadata

Metadata

Assignees

No one assigned

    Labels

    planDurable planning issueplan:waitingPlan is waiting on non-issue evidence or decision

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions