31 lines
1.6 KiB
Markdown
31 lines
1.6 KiB
Markdown
# Codex Workflow
|
|
|
|
Blacksite uses a repository-local workflow to keep implementation fast without weakening acceptance.
|
|
The compact operating rules live in `AGENTS.md`; procedural details live in repository Skills and the
|
|
policies indexed here.
|
|
|
|
## Task lifecycle
|
|
|
|
1. Confirm the canonical repository path, branch, HEAD, dirty state, and active processes.
|
|
2. Resume `.codex/session/STATE.md` when valid instead of rediscovering the repository.
|
|
3. Read `docs/authority.toml`, the smallest relevant current docs, and exact linked tracker items.
|
|
4. Define one bounded slice with acceptance criteria, non-goals, and a verification tier.
|
|
5. Record material user steering as a scope delta, including which evidence remains valid.
|
|
6. Run selective verification, then update canonical docs at the slice boundary.
|
|
7. Treat native acceptance and release-candidate gates as separate states from engineering checks.
|
|
|
|
Ignored `.codex/session/`, `.codex/logs/`, `.codex/cache/`, and `.codex/evidence/` data is working
|
|
state, not documentation. It exists to make reconnects and compaction cheap and must not become a
|
|
second source of product truth.
|
|
|
|
## Policies
|
|
|
|
- [Documentation authority](documentation-policy.md)
|
|
- [Selective verification](verification-policy.md)
|
|
- [Build storage](build-storage-policy.md)
|
|
- [Gitea tracking](gitea-tracking-policy.md)
|
|
|
|
The workflow distinguishes Implementing, Engineering-complete, Acceptance-in-progress,
|
|
Candidate-ready, and Accepted/closed. “Complete” is reserved for the acceptance state actually
|
|
proven; a dirty worktree or source-only check is not closure evidence.
|