30 Commits
main ... v0.0.0

Author SHA1 Message Date
6fa024ddfa docs: add NEWSTART.md and NEWSTART.llm.md capturing all governance, process, and blueprint for a clean repo restart
Some checks are pending
ci / test (push) Waiting to run
2025-09-17 11:40:15 -05:00
11a611e072 governance: make quiet/no-streaming mandatory (no toggle) across system prompts and templates; log in DevLog
Some checks are pending
ci / test (push) Waiting to run
2025-09-17 11:29:53 -05:00
1c22d06566 governance: add Quiet Shell/No Streaming policy; update AGENTS templates; add audit advisory for noisy commands; log in DevLog
Some checks failed
ci / test (push) Has been cancelled
2025-09-17 11:27:13 -05:00
e925e6ebca governance: enforce strict Questions→Proposal→Plan gates with explicit approval phrases; add branching proposal; mark plan pending; audit checks sequencing
Some checks failed
ci / test (push) Has been cancelled
2025-09-17 11:25:05 -05:00
1eaa2f7997 governance: add .gitignore housekeeping and regular audits; implement audit script and CI step; update templates, proposal, and docs
Some checks failed
ci / test (push) Has been cancelled
2025-09-17 11:17:12 -05:00
bae62d94dc docs: add architecture and full audit; fill project templates (.gitignore, scripts/test.sh) per audit findings
Some checks failed
ci / test (push) Has been cancelled
2025-09-17 11:11:07 -05:00
e1b3cd5634 scaffold: add project CI and Docker templates under templates/project/_shared; update proposal and plan to include them
Some checks failed
ci / test (push) Has been cancelled
2025-09-17 11:08:45 -05:00
cf66c9a065 ci: add Gitea Actions workflow and Docker Compose test runner; add test image\n\ngovernance: encode CI/containers rules in system prompts and AGENTS templates; update proposal and docs
Some checks failed
ci / test (push) Has been cancelled
2025-09-17 11:07:06 -05:00
8a55d59804 governance: keep repository root clean; remove marker file; implement repo detection via structure heuristic; update tests and system prompts/templates 2025-09-17 10:39:25 -05:00
c655476699 governance: add planning/architecture rule (plan ahead, module map, avoid refactors); propagate to system prompts, AGENTS templates, proposal, and plan 2025-09-17 10:33:57 -05:00
fae0f5b413 governance: zero technical debt, production-ready always; safety first across system prompts, AGENTS templates, proposal, and plan 2025-09-17 10:31:25 -05:00
ff33cb282a plan: add 8-hour accelerated timeline; maintain TDD across milestones 2025-09-17 10:26:59 -05:00
de8ce1a4dc governance: adopt TDD with full unit/integration tests; update system prompt and AGENTS templates\n\nplan: add TDD milestones and test coverage criteria; update proposal accordingly 2025-09-17 10:26:02 -05:00
3859459754 plan: add Phase 1 implementation plan for CodexHelper (milestones, deliverables, acceptance criteria) 2025-09-17 10:24:04 -05:00
0625682e63 feat: add global system prompt and seed AGENTS templates; update proposal to include meta/ and prompts/global/; add project AGENTS template\n\nchore: update AGENTS.md and dev logs; encode governance/propagation rule 2025-09-17 10:20:49 -05:00
ce0a8b32ec docs: limit chat announcements to collab/{questions,proposals,plan}; update AGENTS.md and SeedPrompt.md; log in devlog 2025-09-17 10:00:04 -05:00
0a9849de52 docs: add strict chat output policy (five-line max, no diffs) to AGENTS.md and SeedPrompt.md; log in devlog 2025-09-17 09:58:14 -05:00
93c63e9810 docs(devlog): move DevLog under docs/; update references in AGENTS.md and SeedPrompt.md 2025-09-17 09:57:30 -05:00
ac36dd8654 docs: add token/context hygiene rules to AGENTS.md and SeedPrompt addendum 2025-09-17 09:55:13 -05:00
f91f3814e8 docs: adopt per-round files + LLM counterparts; add llm versions for 00-bootstrap and 01-codexhelper; update AGENTS and SeedPrompt 2025-09-17 09:54:16 -05:00
2da83b8388 docs(proposal): add 01-codexhelper proposal based on approved questions 2025-09-17 09:52:39 -05:00
ab68196484 docs(questions): replace prior answers section with targeted Explainers responding to back-questions 2025-09-17 09:49:43 -05:00
eea0a2a2c5 docs(questions): add Answers/Explainers 2025-17-09-14:46 summarizing decisions and approach 2025-09-17 09:46:33 -05:00
228db2a3d2 docs(questions): add Followup 2025-17-09-14:33 for CLI UX, templates, prompts, config, safety 2025-09-17 09:33:58 -05:00
cf00a06015 docs(questions): add Followup 2025-17-09-14:21 with targeted clarifications 2025-09-17 09:22:11 -05:00
5ee44431dc docs: enforce questions-first process; remove proposal/plan; update AGENTS and SeedPrompt 2025-09-17 09:19:06 -05:00
a5fa0f8970 docs: note concise chat preference in SeedPrompt addendum 2025-09-17 09:02:24 -05:00
064f3a9d1a chore: restructure collab into questions/proposals/plan subdirs; update references 2025-09-17 09:01:52 -05:00
6dddc7d6b4 chore: add collab/ structure; move questions; add AGENTS.md; addendum in SeedPrompt.md 2025-09-17 08:59:16 -05:00
982679bec5 chore: scaffold devlog and QUESTIONS; capture SeedPrompt.md 2025-09-17 08:55:40 -05:00
58 changed files with 2524 additions and 2 deletions

19
.gitea/workflows/ci.yml Normal file
View File

@@ -0,0 +1,19 @@
name: ci
on:
push:
pull_request:
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Repo audit
run: |
bash scripts/audit.sh
- name: Build and run tests via Docker
run: |
docker compose -f docker/compose.yml up --build --abort-on-container-exit --remove-orphans
docker compose -f docker/compose.yml down -v --remove-orphans

65
AGENTS.md Normal file
View File

@@ -0,0 +1,65 @@
# AGENTS.md — Working Agreements and Conventions
Scope: Applies to the entire repository unless overridden by a deeper AGENTS.md.
Note: The canonical system rules used by the agent are mirrored in `prompts/global/system.md` (human) and `prompts/global/system.llm.md` (LLM). Keep AGENTS.md and the system prompt aligned. A seed AGENTS template for generated projects lives at `meta/AGENTS.seed.md` (and `.llm.md`).
## Collaboration Artifacts
- Root: `collab/`
- Subdirectories: `collab/questions/`, `collab/proposals/`, `collab/plan/`
- Naming per round: `NN-<subject>.md` inside each subdirectory (e.g., `00-bootstrap.md`, `01-codexhelper.md`).
- LLM-optimized copies: add `.llm.md` sibling files (e.g., `01-codexhelper.llm.md`) that are concise and machine-friendly.
- Versioning: start a new numbered file for major rounds rather than expanding one doc indefinitely.
- Principle: Keep chat minimal; prefer file-based collaboration via these documents.
### Sequencing Rules
- Begin with a questions file in `collab/questions/` and iterate there until the agent is satisfied or the user instructs to proceed.
- Do not create a proposal or plan until the questions have been edited by the user and explicitly approved.
- After approval, create a concise proposal in `collab/proposals/` and a concrete plan in `collab/plan/`, then implement.
- One-way progression: once a step (questions → proposal → plan) is approved, do not return to a prior step. Perform any subsequent clarifications/edits within the current steps file for that round (e.g., continue editing `collab/proposals/NN-*.md` after proposal approval) and only create the next steps file when moving forward.
- Artifact edits live in-place: Users/humans will edit the non-LLM `.md` files; the agent reads `.llm.md` and writes both `.md` and `.llm.md` siblings for every collaboration artifact.
### One-Time Exceptions
- Only bypass the Questions→Proposal→Plan cycle when explicitly directed by the user; log such exceptions in `docs/devlog/`.
## Logs and Documentation
- Dev logs: `docs/devlog/DEVLOG_LLM.md` and `docs/devlog/DEVLOG_HUMAN.md` updated each meaningful change.
- Project docs: `docs/` for feature docs (`<feature>.md`) and architectural decisions (`adr-<feature>.md`).
- README: Keep `README.md` current with quickstart and usage.
## Code and Tests
- Add unit tests in `tests/` alongside features as they are introduced.
- Keep changes minimal and focused. Avoid unrelated refactors.
## Git Workflow
- Branch: work on `main` for now.
- Commits: concise, present-tense; Conventional Commits style preferred (e.g., `feat:`, `fix:`, `chore:`).
- Releases/Tags: `YYYY-MM-DD-HHMM` when warranted; use `tea` if configured.
## Wrapper Project Guidelines
- Aim: Bash wrapper around `codex-cli` with modes (global prompt, mode prompt, project prompt, codex settings, MCP).
- Approach: crawl → walk → run. Start with documented defaults and override via flags/env/config.
- Wizards: Intake markdown forms for creating modes and projects.
## Agent Notes
- Ask clarifying questions in `collab/<...>-questions.md`.
- Propose in `collab/<...>-proposal.md`, plan in `collab/<...>-plan.md`, then implement.
- Respect repository structure and this AGENTS.md across all changes.
## Token/Context Hygiene
- Chat minimalism: keep messages short; prefer pointers to files over inline dumps.
- Use `.llm.md` files for concise, machine-friendly summaries; avoid duplicating full human docs.
- Read `.llm.md` for intake; do not rely on `.md` for reading. Write both `.md` and `.llm.md` when updating artifacts.
- No large pastes in chat: never paste large code or markdown; write to files and reference paths/sections.
- Incremental artifacts: start a new `NN-<subject>.md` per round to avoid long single files.
- Status style: one-line updates before tool calls; rely on devlog for detail.
- Avoid re-reading large files in chat; reference exact file paths and sections instead.
## Chat Output Policy
- Default message: `Updated <filepath>. Read/edit and let me know.`
- Keep chat to five lines or fewer.
- Do not paste diffs or file contents in chat; write to files instead.
- Aggregate multiple updates in a short bulleted list of filepaths.
- Push detailed reasoning/status to `docs/devlog/` and reference it when needed.
- Only announce changes to collaboration files: `collab/questions/`, `collab/proposals/`, and `collab/plan/`.
- For all other changes (docs, code, configs), skip chat announcements and log in DevLog.

99
CodexHelper Executable file
View File

@@ -0,0 +1,99 @@
#!/usr/bin/env bash
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
die() { echo "error: $*" >&2; exit 1; }
note() { echo "$*" >&2; }
find_helper_repo_root() {
# Walk upwards to find a dir that looks like the helper repo
local d="$(pwd)"
while [ "$d" != "/" ]; do
if [ -d "$d/collab" ] && [ -f "$d/prompts/global/system.md" ]; then
printf '%s' "$d"
return 0
fi
d="$(dirname "$d")"
done
return 1
}
print_help() {
cat <<EOF
CodexHelper — wrapper for codex-cli with modes and scaffolding
Usage:
CodexHelper new-mode --name <ModeName>
CodexHelper new-project --mode <ModeName> --name <project-name> --path <dir> [--force]
CodexHelper run [--mode <ModeName>] [--prompt-file <file>] [--config <file>] [--sandbox <mode>] [--full-auto]
CodexHelper --help
Notes:
- Inside the CodexHelper repo, only 'new-mode' is allowed.
- Outside the repo, 'new-project' and 'run' are allowed.
EOF
}
require_outside_repo_for() {
local subcmd="$1"
if find_helper_repo_root >/dev/null 2>&1; then
if [ "$subcmd" != "new-mode" ]; then
die "Only 'new-mode' is allowed when running inside the CodexHelper repository"
fi
fi
}
detect_codex() {
if [ -n "${CODEX_BIN:-}" ]; then echo "$CODEX_BIN"; return 0; fi
if command -v codex >/dev/null 2>&1; then echo codex; return 0; fi
if command -v codex-cli >/dev/null 2>&1; then echo codex-cli; return 0; fi
die "No codex binary found. Set CODEX_BIN or install 'codex'/'codex-cli' in PATH."
}
cmd_new_mode() {
local name=""
while [ $# -gt 0 ]; do
case "$1" in
--name) name="$2"; shift 2;;
--force) FORCE=1; shift;;
--help|-h) print_help; exit 0;;
*) die "Unknown option for new-mode: $1";;
esac
done
[ -n "$name" ] || die "--name is required"
local dir="modes/$name"
if [ -e "$dir" ] && [ -z "${FORCE:-}" ]; then
die "Mode '$name' already exists. Use --force to overwrite."
fi
mkdir -p "$dir"
: >"$dir/mode.md"
: >"$dir/defaults.yaml"
note "Created $dir/mode.md and $dir/defaults.yaml"
}
cmd_new_project() {
require_outside_repo_for new-project
# Implementation follows in later milestones
die "Not yet implemented: new-project (per plan)."
}
cmd_run() {
require_outside_repo_for run
# Implementation follows in later milestones
die "Not yet implemented: run (per plan)."
}
main() {
local subcmd="${1:-}"; if [ -z "$subcmd" ] || [ "$subcmd" = "--help" ] || [ "$subcmd" = "-h" ]; then
print_help; exit 0
fi
case "$subcmd" in
new-mode) shift; cmd_new_mode "$@";;
new-project) shift; cmd_new_project "$@";;
run) shift; cmd_run "$@";;
*) die "Unknown subcommand: $subcmd";;
esac
}
main "$@"

18
NEWSTART.llm.md Normal file
View File

@@ -0,0 +1,18 @@
# NEW START — LLM
- Non-negotiables: zero-debt; TDD; plan-first; quiet chat; containers-first; CI parity; clean root; audits.
- Gates (human .md phrases): Questions→“Approved for Proposal”; Proposal→“Approved for Plan”; Plan→“Approved to Implement”.
- Chat: announce collab files only; ≤5 lines; no content/diff streaming.
- Quiet tooling: use scripts/toolwrap.sh; success → no chat; failure → append stdout/stderr to docs/devlog/tool.log.
- Audits: run scripts/audit.sh regularly and pre-release; store in docs/audits/.
- CI/containers: Gitea Actions + local Docker Compose; dependencies via images; explicit names; cleanup; mount host config if needed.
- .gitignore: include runs/ + OS files; keep current.
- Layout: collab/, docs/, prompts/global/, modes/, templates/project/_shared/, scripts/, .gitea/.
- Wrapper (MVP): subcommands new-mode (repo-only), new-project (outside), run (outside). Guardrails enforced.
- Prompt order: global system → mode system? → mode rules → project narrative.
- Config via yq: global < mode < project < ENV < CLI.
- Project scaffold: AGENTS.md; prompts/{project.md,style.md?}; prompts/_mode; codex.yaml; codex.sh; CI (gitea); docker/compose.yml + test/Dockerfile; scripts/{test.sh,test.docker.sh,audit.sh}; .gitignore; runs/.
- Tests: bats/internal; cover CLI/guardrails/scaffold/composition/precedence.
- Branching (recommended): trunk-based; protected main; short-lived branches; tags YYYY-MM-DD-HHMM; required checks; Conventional Commits.
- Start checklist: commit clean skeleton; add NEWSTART docs; start with Questions 00; use toolwrap + DevLogs; add audits early.

113
NEWSTART.md Normal file
View File

@@ -0,0 +1,113 @@
# New Start — CodexHelper Project Blueprint
Purpose
- Capture everything we learned so far and define a clean, production-ready blueprint for a fresh repository using CodexHelper. This document is human-focused; see NEWSTART.llm.md for the compact machine version.
Guiding Principles (Non-Negotiable)
- Safety first, speed second. Zero technical debt at all times; every commit is production-ready.
- TDD by default. Write failing tests first; make them pass; refactor.
- Plan first, implement second. Strict Questions → Proposal → Plan → Implement.
- Quiet, file-first collaboration. Chat is minimal; files and logs carry the detail.
- Containers-first, with CI parity between local and Gitea.
- Clean repository roots and predictable scaffolding.
Process & Governance
- Sequencing (Strict Gates)
- Questions → Proposal → Plan → Implement (one-way progression; no backsteps after approval).
- Approvals must use exact phrases in the human .md file:
- Questions approval: “Approved for Proposal”
- Proposal approval: “Approved for Plan”
- Plan approval: “Approved to Implement”
- Agent reads `.llm.md`; humans edit `.md`. Agent writes both siblings for each artifact.
- Chat Output Policy
- Default: “Updated <filepath>. Read/edit and let me know.”
- ≤5 lines; do not stream file contents or diffs in chat.
- Announce only collab files (questions/proposals/plan). Everything else goes to DevLog.
- Quiet Shell, Tool Logging
- Quiet is mandatory (no toggle). Use silent checks and avoid printing command output.
- Use `scripts/toolwrap.sh` to run host commands quietly.
- On success: no chat output; brief SUCCESS line is logged to `docs/devlog/tool.log`.
- On failure (not sandbox): append full stdout/stderr + timestamp + command to `docs/devlog/tool.log`.
- TDD & Quality
- Tests live under `tests/`; provide `scripts/test.sh` and `scripts/test.docker.sh`.
- Add tests for every feature; keep tests fast and focused.
- No unrelated refactors; fix root causes.
- Architecture & Planning
- Maintain `docs/architecture.md` and ADRs for significant decisions.
- Design module boundaries up front to avoid refactors; if assumptions change, update Questions/Proposal/Plan and docs before changing code.
- Clean Roots & .gitignore Housekeeping
- Keep root minimal; organize assets under `docs/`, `templates/`, `collab/`, `prompts/`, `modes/`, `scripts/`, `meta/`, `.gitea/`.
- Include `.gitignore` with `runs/` and common OS files; keep it current.
- CI/Containers (Gitea + Docker)
- CI uses Gitea Actions (`.gitea/workflows/`) and must mirror local Docker Compose.
- Do work in containers when appropriate; host is for git/tea and Docker orchestration only.
- Dependencies (e.g., bats, yq) are provided via Docker images; avoid host installs.
- Naming hygiene for containers/networks; explicit names; ensure cleanup.
- Where host auth/config is required (e.g., codex), mount config dirs into the container securely.
- Audits (Regular and Pre-Release)
- Run `scripts/audit.sh` regularly and before any release tag.
- Audit checks: governance compliance (gates, quiet policy), structure, .gitignore, CI parity, tests present.
- Record audits in `docs/audits/` and summarize in DevLogs.
Branching & Releases (Recommended)
- Trunk-based development:
- `main` is protected, always green, production-ready.
- Short-lived branches by type: `feat/*`, `fix/*`, `chore/*`, `docs/*`, `ci/*`, `refactor/*`.
- Optional `next` only if batching risky work.
- Protections: required checks (audit + Docker tests), PRs required, Conventional Commits, linear history or squash.
- Tags: `YYYY-MM-DD-HHMM` for release-ready commits on `main` only.
Repository Layout (Clean Start)
- collab/ — questions/, proposals/, plan/ (each step has `NN-<subject>.md` + `.llm.md`).
- docs/ — devlog/, audits/, architecture.md, feature docs, ADRs.
- prompts/ — `global/system.md` and `.llm.md` (canonical rules); modes/ live in `modes/`.
- modes/ — `<ModeName>/{mode.md, system.md?, defaults.yaml}`.
- templates/ — project scaffolding, including `_shared` with AGENTS.md, CI, docker, scripts.
- scripts/ — `test.sh`, `test.docker.sh`, `audit.sh`, `toolwrap.sh`.
- .gitea/ — workflows for CI.
CodexHelper (Wrapper) — MVP Blueprint
- Goals
- Provide modes (global/mode/project prompts), project scaffolding, prompt composition, config precedence, and safe defaults around `codex`/`codex-cli`.
- CLI (subcommands)
- `new-mode` (repo-only): scaffold `modes/<Name>/{mode.md, defaults.yaml, system.md?}`.
- `new-project` (outside repo): scaffold project structure (see below).
- `run` (outside repo): compose prompts and invoke codex, writing to `runs/<ts>/`.
- Binary Detection
- `CODEX_BIN` env > `which codex` > `which codex-cli`; fail with a helpful message otherwise.
- Prompt Composition
- Order: Global system → Mode system overlay (optional) → Mode rules → Project narrative.
- Config Precedence (YAML + yq)
- global defaults < mode defaults < project config < ENV < CLI.
- Safety
- Require `--force` to overwrite; never run `git push` for user projects.
- Project Scaffolding (Generated Project Layout)
- `AGENTS.md` (from template)
- `prompts/project.md` (+ optional `prompts/style.md`)
- `prompts/_mode/` (read-only copies of global/mode prompts)
- `codex.yaml` (project settings)
- `codex.sh` (entrypoint to compose and call codex)
- `.gitea/workflows/ci.yml` (CI) + `docker/compose.yml` + `docker/test/Dockerfile`
- `scripts/test.sh` + `scripts/test.docker.sh` + `scripts/audit.sh`
- `.gitignore` (includes `runs/`)
- `runs/` (created on first run; ignored by VCS)
Acceptance (Phase 1 Crawl”)
- `new-mode` creates mode skeleton; refuses overwrites unless `--force`.
- `new-project` scaffolds all files above without overwrites; includes CI and Docker artifacts.
- `run` composes prompts in the right order and invokes the detected codex binary; artifacts under `runs/<timestamp>/`.
- Config precedence enforced via yq.
- Guardrails: inside the helper repo only `new-mode` is allowed; elsewhere `new-project`/`run` allowed.
- Tests (bats or internal): cover CLI, guardrails, scaffolding, composition, precedence.
- CI: Gitea workflow executes audit and Docker-based tests; local Docker run mirrors CI.
Start-From-Scratch Checklist (New Repo)
1) Commit clean skeleton: collab/, docs/, prompts/global/, templates/_shared, scripts/, .gitea/.
2) Add `NEWSTART.md` and `NEWSTART.llm.md` (this pair) and `docs/architecture.md`.
3) Begin with `collab/questions/00-bootstrap.{md,llm.md}`; do not proceed without Approved for Proposal”.
4) Keep chat minimal; use toolwrap and DevLogs. Add audits early.
5) Implement Phase 1 via TDD, following QuestionsProposalPlan gate for each subject.
Notes
- This blueprint is the canonical source for repository setup and workflow. Keep it in sync with prompts/global/system.md.

View File

@@ -1,3 +1,18 @@
# ChatGPTScaffolding
# ChatGPTScaffolding / CodexHelper
Scaffolding (prompts/personas/modes/rules etc) around codex-cli. Tuned for @ReachableCEO needs as a solo entrepreneur. Developed from scratch in an afternoon after three weeks of intense AI usage across multiple providers/systems.
Scaffolding (prompts/personas/modes/rules etc) around codex-cli. Tuned for @ReachableCEO needs as a solo entrepreneur.
CodexHelper adds:
- Modes (global/mode/project prompts)
- Project scaffolding
- Prompt composition and safe defaults
- Governance: TDD, zero technical debt, plan-first via Questions → Proposal → Plan
Status: Phase 1 in progress — `new-mode` implemented; `new-project` and `run` coming next.
Quickstart (dev)
- Run tests: `scripts/test.sh` (uses bats if available)
- Show help: `./CodexHelper --help`
- Create a demo mode (in this repo): `./CodexHelper new-mode --name Demo`
See `docs/wrapper.md` and `prompts/global/` for details and governance rules.

78
SeedPrompt.md Normal file
View File

@@ -0,0 +1,78 @@
(We are in a codex-cli session and i've instructed it to read this file but given it no other instructions)
## Meta Rules
- Please keep a development log of your work (In both llm optimized form and human readable form ) (separate files) (in a subdirectory called devlog)
- Please commit frequently and push/tag a release (YYYY-MM-DD-HHMM) (using the tea command) when you feel it's warranted (all work is done on main for now)
- Please create and maintain README.md and a docs/ directory with <feature>.md and <adr-feature>.md as we go
- Please create and maintain unit tests as we go in a tests/ directory
## Ultimate goal of this project
A wrapper bash script around codex-cli allowing the use of "modes" which will be a collection of
- A fixed Global system prompt
- A fixed Mode prompt
- A variable (user defined) project specific prompt
- Codex settings (model/token budget/reasoning level etc)
- MCP configuration
Also:
- A "wizard" to create new modes (by filling out a markdown file intake form)
- A "wizard" to create new projects (by filling out a markdown file intake form)
## Approach
Lets "crawl/walk/run" , starting with a simple wrapper script for codex-cli that has (documented) defaults set but also allows (via command line flags/environment variables/config file) over-riding the options
This should be very collaborative. Ask questions (in a markdown file), once they are answered then create a proposal for review/approval, then create a plan for review/approval. Then once everything is approved, implement the code for review and approval.
I want to be able to test the code early/often and be able to provide feedback. I want to be able to edit markdown files inline to provide context/ask questions etc as we go. The chat interface itself should be kept very clean as it's running in the bottom of my vscode instance and I want to use vscode markdown facilities to rapidly read/edit the markdown files. So our primary way of interacting
will be via those files.
Commit/push everything in the repo now before we get started on the project.
---
## Addendum (Housekeeping) — 2025-09-17
- Create and use a `collab/` directory for coordination artifacts.
- Under `collab/`, create subdirectories: `questions/`, `proposals/`, and `plan/`.
- Use consistent filenames: `<step-or-subject>.md` inside each subdirectory.
- Move existing files accordingly (e.g., `collab/questions/00-bootstrap.md`).
- Create and maintain an `AGENTS.md` at the repo root with working agreements and conventions.
- Continue keeping `docs/devlog/DEVLOG_LLM.md` and `docs/devlog/DEVLOG_HUMAN.md` updated.
- After applying this structure, commit and push the changes.
### Chat Output Preference
- Keep chat output concise and minimal. The primary collaboration interface is via repository files (collab/, devlog/, docs/). Use chat only for brief status updates or to announce next actions.
### Collaboration Sequencing
- Start with questions in `collab/questions/` and keep iterating/adding questions until satisfied or instructed to move on.
- Do not create proposals or plans until the questions file has been edited by the user and the user gives explicit approval.
### Files Per Round + LLM Copies
- Use multiple files per round rather than growing a single document.
- Naming: `collab/<type>/NN-<subject>.md` (human) and `collab/<type>/NN-<subject>.llm.md` (LLM-optimized).
- Start a new `NN` for each major round; keep subject consistent across types.
### Token Discipline
- Keep chat output extremely concise; use the filesystem (docs/devlog, collab/) for details.
- Summarize for the model in `.llm.md` companions; keep human-readable detail in the primary `.md`.
- Do not paste large content into chat; write to files and reference paths.
- Prefer starting new numbered files per round to keep each doc short.
### Chat Output Policy
- Default chat line: `Updated <filepath>. Read/edit and let me know.`
- Limit chat to five lines or fewer; avoid explanations in chat.
- Never paste diffs or large content in chat; commit to files and reference paths.
- Log detail in `docs/devlog/` and keep the chat terminal clean.
- Only announce updates for `collab/questions/`, `collab/proposals/`, and `collab/plan/` files. All other updates go to DevLog without chat noise.

View File

@@ -0,0 +1,67 @@
# 01 — CodexHelper — Implementation Plan (LLM)
- Scope: Phase 1 (Crawl) MVP for `CodexHelper` with subcommands, scaffolding, prompt composition, config precedence, and safety.
- Milestones (TDD for each step):
0) Test harness setup (bats-core), tests/ structure, CI script (local)
1) CLI skeleton + guardrails (write failing tests first)
2) Binary detection + pass-through flags (tests first)
3) new-mode scaffolder (repo-only) (tests first)
4) new-project scaffolder (outside repo) (tests first)
5) run: compose prompts + invoke codex (tests first)
6) Config precedence (YAML+yq) (tests first)
7) Templates + copies (AGENTS.md, prompts/_mode) (tests first)
8) Docs: README quickstart + wrapper usage (ensure examples validated by tests where feasible)
- Key rules honored:
- One-way workflow; minimal chat; read `.llm.md`, write both.
- Governance/propagation: update prompts/global and seed/project AGENTS when norms change.
- Safety: `--force` for overwrite; never `git push`; runs under `<project>/runs/<ts>/`.
- Zero Technical Debt: production-ready always; no deferring docs/tests/refactors.
- Planning/Architecture: plan ahead; maintain architecture/module map; implement module-by-module; avoid refactors unless plans/docs updated due to new info.
- Deliverables:
- `CodexHelper` bash script
- `prompts/global/{system.md,system.llm.md}` (already present)
- `templates/project/_shared/AGENTS.md` (copy into project root)
- `templates/project/<ModeName>/...` (optional mode-specific add-ons; start minimal)
- `docs/wrapper.md` and README updates
- Test harness (`bats`), `tests/` with coverage of all CLI paths
- `docs/architecture.md` and ADRs for key decisions
- Implementation details:
- Guard where running: inside repo → only `new-mode` allowed.
- Detect codex: `CODEX_BIN` env > `which codex` > `which codex-cli`.
- new-mode: create `modes/<Name>/{mode.md,defaults.yaml,system.md?}` with intake hints.
- new-project: create dir, copy `AGENTS.md`, `prompts/project.md`, `prompts/style.md?`, `prompts/_mode/` with read-only copies of global+mode prompts, `codex.yaml`, `codex.sh`, `.gitignore` (includes `runs/`).
- run: ensure project layout; compose prompts in order: global system → mode system? → mode rules → project narrative; call `$CODEX_BIN` with pass-through flags; write logs/artifacts to `runs/<ts>/`.
- Config precedence: load YAML via yq; allow CLI/env override of codex settings and mode.
- Acceptance checks:
- Running in repo: `new-mode` works; `run`/`new-project` error with guidance.
- `new-project` scaffolds without overwrites; includes `AGENTS.md`; sets up `prompts/_mode/`.
- `run` composes prompts and calls detected binary; artifacts under `runs/<ts>/`.
- Precedence: CLI > env > project > mode > global.
- `prompts/global/` used in composition.
- Tests: all features covered by unit/integration tests (bats); TDD observed (tests committed alongside implementation); CI/local test script present.
- Zero Debt: docs updated; no pending TODOs/deferrals; production-ready criteria met.
- Planning/Architecture: architecture/module map exists and matches implemented modules; no unplanned refactors.
- Open choices (defaulting now):
- Include empty `prompts/style.md`: Yes.
- Config format: YAML only; tool: yq.
- Project `.gitignore`: include `runs/` and any `*.llm.*` if user prefers later (for now, only `runs/`).
- Test framework: bats-core for bash; simple runner `scripts/test.sh`.
- Next: Implement per milestones; add concise README quickstart.
- Accelerated Timeline (8 hours today):
- H01: test harness + failing smoke tests (CLI, guardrails)
- H12: CLI skeleton + guardrails (make tests pass)
- H23: binary detection + pass-through (tests first)
- H34: new-mode scaffolder (tests first)
- H46: new-project scaffolder (tests first)
- H67: run: compose + invoke (tests first)
- H78: config precedence (tests first) + minimal docs
- No deferral: docs must be completed; templates polished sufficiently for production.

View File

@@ -0,0 +1,78 @@
# 01 — CodexHelper — Implementation Plan
Purpose: Deliver Phase 1 (Crawl) MVP of CodexHelper: subcommands, scaffolding, prompt composition, config precedence, and safety.
## Milestones & Tasks (TDD)
0) Test harness setup
- Add `tests/` directory and `scripts/test.sh` using bats-core (document installation/usage).
- Write initial smoke tests that will fail until implementation exists.
0a) Architecture & Module Map
- Create `docs/architecture.md` summarizing global architecture, module boundaries, and responsibilities for Phase 1.
- Add or update ADRs as needed for key decisions.
1) CLI skeleton + guardrails (tests first)
- Write tests for `--help`, subcommands, and location guardrails.
- Implement `CodexHelper` with `new-project`, `run`, `new-mode` and enforce location rules.
2) Binary detection + pass-through (tests first)
- Write tests for `CODEX_BIN`, `codex`, `codex-cli` resolution and pass-through flags.
- Implement `detect_codex` and flag forwarding.
3) new-mode (repo-only) (tests first)
- Write tests for scaffolding `modes/<Name>/...` and `--force` behavior.
- Implement creation with intake comments and overwrite safeguards.
4) new-project (outside repo) (tests first)
- Write tests for project directory creation, copying AGENTS.md, prompts, codex.yaml, codex.sh, `.gitignore` content, and CI/containers artifacts (`.gitea/workflows/ci.yml`, `docker/compose.yml`, `docker/test/Dockerfile`, `scripts/test.docker.sh`).
- Implement scaffolding and read-only copies under `prompts/_mode/`.
5) run: compose + invoke (tests first)
- Write tests for prompt composition order, `runs/<timestamp>/` outputs, and invocation args.
- Implement composition and execution using `$CODEX_BIN`.
6) Config precedence (YAML + yq) (tests first)
- Write tests covering precedence: global < mode < project < env < CLI.
- Implement merging with `yq` and apply overrides.
7) Docs (no deferral)
- Add `docs/wrapper.md` with usage examples and config reference.
- Update `README.md` quickstart: installation, basic flows.
- Ensure docs updated in the same commit as features.
## Safety & Policies
- Never overwrite without `--force`.
- Never `git push` for user projects.
- Write outputs to `<project>/runs/<timestamp>/...`.
- Minimal chat; read `.llm.md`, write both `.md` and `.llm.md` for collab artifacts.
- Governance/Propagation: reflect future non-project-specific norms into `prompts/global/` and AGENTS templates; log in DevLog.
- TDD default: write failing tests before implementing features; require unit/integration tests for all new functionality in this repo and generated projects.
- Zero Technical Debt: safety first; no technical debt; always production-ready; do not defer tests/docs/refactors; use sub-agents as needed to maintain quality and speed.
- Planning/Architecture: align via QuestionsProposalPlan; maintain `docs/architecture.md` and ADRs; avoid refactors except when plans/docs are updated due to new information.
## Acceptance Criteria
- Inside this repo: `CodexHelper new-mode --name Demo` creates `modes/Demo/{mode.md,defaults.yaml}` (and optional `system.md`) and refuses overwrites without `--force`.
- Outside this repo: `CodexHelper new-project --mode Demo --name demo --path /tmp` creates project with `AGENTS.md`, `prompts/{project.md,style.md}`, `prompts/_mode/` (copies of global+mode), `codex.yaml`, `codex.sh`, `.gitignore` (with `runs/`).
- Inside the new project: `CodexHelper run --full-auto` composes prompts and calls detected binary; artifacts under `runs/<timestamp>/...`.
- Precedence: CLI > env > project > mode > global.
- `prompts/global/{system.md,system.llm.md}` are present and included in composition.
- Running `CodexHelper run` or `new-project` inside this repo errors with guidance.
- Tests: bats test suite covers all CLI paths and guardrails; tests pass locally; test runner script present.
- Project CI: scaffold contains Gitea workflow and Docker artifacts for local parity.
## Assumptions/Risks
- codex-cli flags may vary; well design pass-through and document tested flags.
- `yq` is available; if missing, we provide a helpful error.
- bats-core availability assumed; if not present, document installation and provide graceful skip with clear message.
## Timeline (targeted)
Accelerated (8 hours today):
- Hour 01: Test harness setup; write failing smoke tests (CLI, guardrails)
- Hour 01 (parallel): Draft `docs/architecture.md` (module map) and commit
- Hour 12: Milestone 1 — CLI skeleton + guardrails (make tests pass)
- Hour 23: Milestone 2 — Binary detection + pass-through (tests first)
- Hour 34: Milestone 3 — new-mode scaffolder (tests first)
- Hour 46: Milestone 4 — new-project scaffolder (tests first)
- Hour 67: Milestone 5 — run: compose + invoke (tests first)
- Hour 78: Milestone 6 — Config precedence (tests first); finalize quickstart docs
- Ongoing: Maintain/expand tests with each feature change (TDD).

View File

@@ -0,0 +1,24 @@
# 02 — Branching/Release — Plan (LLM)
- Model: Trunk-based with protected `main` (always green, production-ready) + short-lived feature branches (`feat/*`, `fix/*`, `chore/*`, `docs/*`, `ci/*`, `refactor/*`). Optional `next` integration branch only if batching risky work.
- Repo content on `main`: Full repo (code, prompts, templates, docs) — must pass CI and audits on every merge.
- Tags: `YYYY-MM-DD-HHMM` on release-ready commits.
- CI protections: Required checks (audit + Docker tests), linear history, PR required, Conventional Commits.
- Migration steps:
1) Tag current good baseline (e.g., `YYYY-MM-DD-HHMM`).
2) Create `wip/phase1` branch from current `main`; continue all WIP there under PRs to `main`.
3) Enable protections on `main` in Gitea: required checks (audit/test), PR reviews, linear history.
4) Document policy in `docs/branching.md` and update README.
5) Add templates/docs for downstream projects to adopt same policy (if needed).
- Acceptance:
- `main` protected with required CI checks; PR required; Conventional Commits enforced.
- `wip/phase1` exists; ongoing work targets it.
- Tags used only for release-ready commits on `main`.
- `docs/branching.md` present and referenced by README.
- Notes:
- Reassess `next` only if multiple parallel risky features emerge.
- Keep branches short-lived; delete after merge.

View File

@@ -0,0 +1,37 @@
# 02 — Branching/Release — Plan
# Status: Pending Proposal Approval — do not execute until 02-branching proposal is approved (“Approved for Plan”).
Purpose: Keep `main` production-ready and clean while enabling fast, safe iteration via short-lived branches and CI protections.
## Chosen Model
- Trunk-based development:
- `main` is always green and production-ready (zero technical debt).
- Work happens on short-lived branches by type: `feat/*`, `fix/*`, `chore/*`, `docs/*`, `ci/*`, `refactor/*`.
- Optional `next` integration branch only if batching risky changes is necessary.
## Repo Content on `main`
- Full repository (code, prompts, templates, docs). Every merge must pass audits and Docker-based CI.
- Releases tagged `YYYY-MM-DD-HHMM` on `main` only.
## CI/Gitea Protections
- Required checks on `main`: scripts/audit.sh and Docker test job.
- Require PRs to merge; block direct pushes.
- Enforce linear history (no merge commits) or squash-merge per preference.
- Enforce Conventional Commits in PR titles.
## Migration Steps
1) Tag current baseline on `main` (e.g., `YYYY-MM-DD-HHMM`).
2) Create `wip/phase1` from current `main`; continue TDD work there.
3) Configure Gitea branch protection for `main` with required checks and PR requirement.
4) Add `docs/branching.md` describing this policy; link from README.
5) Optionally create `next` if multiple risky features need integration before `main`.
## Acceptance Criteria
- `main` is protected in Gitea with required audit/test checks and PR-only merges.
- `wip/phase1` branch exists and becomes the target for ongoing work until Phase 1 is complete.
- Tags are created only on `main` for release-ready states.
- `docs/branching.md` added and referenced by README.
## Notes
- Keep branches short-lived; delete after merge.
- If policy changes, update `docs/branching.md`, AGENTS templates, and prompts/global to propagate.

View File

@@ -0,0 +1,56 @@
# 01 — CodexHelper — Proposal (LLM)
- Tool: `CodexHelper` bash wrapper for codex-cli.
- CLI (subcommands):
- new-project: scaffold project files
- run: compose prompts + call codex
- new-mode: scaffold mode (repo-only)
- Where to run: repo → only new-mode; elsewhere → new-project, run.
- Prompts order: global system → mode system overlay (optional) → mode rules → project narrative.
- Config: YAML + yq; precedence CLI > env > project > mode > global.
- Binary: detect `codex` then `codex-cli`; override `CODEX_BIN`.
- Safety: no overwrites without `--force`; never `git push` for user projects.
- Outputs: `<project>/runs/<ts>/...`.
- Layout (repo): `CodexHelper`, `bin/install.sh`, `prompts/global/{system.md,system.llm.md}`, `modes/<Name>/{mode.md,system.md?,defaults.yaml}`, `templates/project/<Name>/...`, `templates/project/_shared/AGENTS.md`, `meta/{AGENTS.seed.md,AGENTS.seed.llm.md}`.
- Layout (project): `AGENTS.md`, `prompts/{project.md,style.md?}`, `prompts/_mode/`, `codex.yaml`, `codex.sh`, `runs/`, `.gitea/workflows/`, `docker/`, `scripts/`.
- Governance/Propagation: non-project-specific workflow changes get recorded in `prompts/global/` and seed AGENTS templates; proposal/plan updated so scaffolding includes them.
- TDD Governance: adopt test-driven development with full unit/integration tests for all features in this repo and generated projects; tests written first and required for acceptance.
- Zero Technical Debt: safety first; no technical debt; production-ready at all times; no deferring tests/docs/refactors; use sub-agents as needed.
- Planning/Architecture Governance: plan ahead via Questions→Proposal→Plan; maintain a global architecture/module map; implement module-by-module; avoid refactors except when assumptions change and plans/docs are updated.
- Clean Root Governance: keep repo root minimal; organize assets under `docs/`, `templates/`, `collab/`, `prompts/`, `modes/`, `scripts/`, `meta/`.
- CI/Containers Governance: use Gitea Actions with local parity via Docker Compose; do work inside containers; host for git/tea + Docker orchestration; dependencies via Docker; explicit names/cleanup.
- .gitignore Governance: maintain `.gitignore` with `runs/` and OS ignores across repos and generated projects.
- Audits Governance: run audits regularly; prompt before releases; record under `docs/audits/`; enforce via CI step.
- Phase 1 acceptance:
- new-mode creates mode skeleton
- new-project scaffolds without overwrites
- run composes and calls detected codex; writes under runs/
- precedence respected; running in repo errors for run/new-project
- new-project copies `templates/project/_shared/AGENTS.md` into project root as `AGENTS.md`
- prompts/global present and used in prompt composition
- governance rule: changes to global norms propagate to prompts/global and AGENTS templates; logged in DevLog
- tests: unit/integration tests (bats) cover CLI flows and guardrails; TDD observed
- zero debt: docs/tests included with every feature; no pending TODOs/deferrals; production-ready criteria met
- planning: architecture/module map documented; module implementations follow approved plan with no unplanned refactors
- clean root: root remains minimal; scaffolding organizes assets under subdirectories
- ci/containers: Gitea Actions and local Docker Compose run identical workflows; explicit names and cleanup verified
- project CI: scaffold includes `.gitea/workflows/ci.yml`, `docker/compose.yml`, `docker/test/Dockerfile`, and `scripts/test.docker.sh`
- audits: audit script present and run in CI; reports recorded in repo when performed
- ci/containers: Gitea Actions and local Docker Compose run identical workflows; explicit names and cleanup verified
\n+## Approval — Tick All That Apply
- Subcommands approved: `new-project`, `run`, `new-mode` [ ]
- Scope approved: repo→`new-mode` only; outside→`new-project`/`run` [ ]
- Prompts order approved: global→mode-system?→mode→project [ ]
- Config+precedence approved: YAML+yq; CLI>ENV>project>mode>global [ ]
- Safety approved: `--force` to overwrite; no `git push`; outputs to `<project>/runs/<ts>/...` [ ]
- Repo layout approved (modes, templates, global prompts) [ ]
- Project layout approved (prompts, `_mode/`, codex.yaml, codex.sh, .gitignore) [ ]
- Include empty `prompts/style.md` by default [ ]
- Binary discovery: `codex``codex-cli`; override `CODEX_BIN` [ ]
- Pass-through flags: `--mode --prompt-file --config --sandbox --full-auto` [ ]
- Block `run`/`new-project` inside repo with helpful error [ ]
- Phase 1 (Crawl) scope acceptable [ ]
- Add `docs/ROADMAP.md`; MCP deferred [ ]
Final: Reply in the human doc with “Approved for Plan” when all are checked.

View File

@@ -0,0 +1,139 @@
# 01 — CodexHelper — Proposal
Purpose: Implement a bash wrapper (CodexHelper) around codex-cli with “modes”, project scaffolding, and a clean CLI.
## Summary of Agreed Direction
- Name/Install: `CodexHelper` script in this repo; users add it to PATH. Optional `bin/install.sh` to symlink into `~/bin`.
- CLI Style: Subcommands — `new-project`, `new-mode`, `run`.
- Where to run: Outside this repo → `new-project`, `run`. Inside this repo → only `new-mode`.
- Modes/Prompts: Global system (repo-wide) → optional mode system overlay → mode rules → project narrative.
- Config: YAML with `yq`. Precedence: CLI > env > project > mode > global defaults.
- Binary discovery: `which codex`, then `which codex-cli`; override with `CODEX_BIN`. No auto-install.
- Safety/Outputs: Never overwrite without `--force`; never `git push` in user projects; write runs to `<project>/runs/<timestamp>/...`.
- Licensing: Repo (wrapper, modes, prompts) AGPLv3; user artifacts are user-licensed.
- OS/Deps: Ubuntu/Debian, bash/zsh; deps: bash, git, yq.
## CLI
- `CodexHelper new-project --mode <ModeName> --name <project-name> --path <dir> [--force] [--sandbox <mode>] [--full-auto] [--config <file>]`
- Creates project structure in `<dir>/<project-name>` (or `<dir>` if it exists):
- `prompts/project.md` (narrative template), optional `prompts/style.md`
- `prompts/_mode/` with copies of global/mode prompts
- `codex.yaml` (mode + settings + MCP placeholders)
- `codex.sh` (entrypoint wrapper that resolves config and calls `codex`)
- `.gitignore` (includes `runs/`)
- `CodexHelper run [--mode <ModeName>] [--prompt-file <file>] [--config <file>] [--sandbox <mode>] [--full-auto] [--force]`
- Must be run inside a project dir; composes prompts in correct order; writes logs to `runs/<timestamp>/...`.
- Respects precedence: CLI > env > project > mode > global.
- `CodexHelper new-mode --name <ModeName>` (only in this repo root)
- Scaffolds `modes/<ModeName>/mode.md` and optional `modes/<ModeName>/system.md`, plus `modes/<ModeName>/defaults.yaml`.
- Uses a markdown intake template for quick editing.
## Repository Layout (this repo)
- `CodexHelper` (bash)
- `bin/install.sh` (optional symlink helper)
- `prompts/global/{system.md, system.llm.md}` (global system rules; human + LLM)
- `modes/<ModeName>/mode.md` (mode rules)
- `modes/<ModeName>/system.md` (optional mode-specific system overlay)
- `modes/<ModeName>/defaults.yaml` (default codex settings, optional MCP placeholders)
- `templates/project/<ModeName>/...` (project scaffolding templates copied on `new-project`)
- `templates/project/_shared/AGENTS.md` (AGENTS template copied into projects)
- `meta/{AGENTS.seed.md, AGENTS.seed.llm.md}` (seed AGENTS templates for bootstrap/reference)
- Governance/Propagation: maintain global norms in `prompts/global/` and seed AGENTS templates; reflect such changes in proposal/plan for scaffolding.
- TDD Governance: enforce test-driven development; require unit/integration tests for all features here and in generated projects.
- Zero Technical Debt: safety first; always production-ready; no deferring tests/docs/refactors; leverage sub-agents when needed.
- Planning/Architecture Governance: plan ahead via Questions→Proposal→Plan; keep a global architecture/module map; implement module-by-module; avoid refactors except when assumptions change and plans/docs are updated.
- Clean Root Governance: keep repo root minimal; organize assets under `docs/`, `templates/`, `collab/`, `prompts/`, `modes/`, `scripts/`, `meta/`.
- CI/Containers Governance: use Gitea Actions with local parity via Docker Compose; do work inside containers; host for git/tea and Docker only; dependencies via Docker; explicit names and cleanup.
- .gitignore Governance: include and maintain `.gitignore` entries (e.g., `runs/`, OS files) across repos and generated projects.
- Audits Governance: perform regular audits; prompt before releases; store reports under `docs/audits/` and enforce via CI step.
## Project Layout (generated)
- `AGENTS.md` (from `templates/project/_shared/AGENTS.md`)
- `prompts/project.md` (+ optional `prompts/style.md`)
- `prompts/_mode/` (read-only copies from this repo)
- `codex.yaml` (project config)
- `codex.sh` (entrypoint wrapper around codex-cli)
- `runs/` (created on first run; ignored by VCS)
- `.gitea/workflows/` for CI; `docker/` for compose and Dockerfiles; `scripts/` for docker orchestration (tests, ci)
## Config Details
- Format: YAML (`yq` for merging/reading)
- Precedence resolution: merge defaults in order — global defaults → mode defaults → project config → env vars → CLI flags.
- Key fields in `codex.yaml`:
- `mode: <ModeName>`
- `codex:` `{ model, token_budget, reasoning_level, sandbox, full_auto, extra_args[] }`
- `prompts:` `{ project: prompts/project.md, mode_dir: prompts/_mode }`
- `mcp:` placeholders (deferred per roadmap)
## Prompt Composition
- Order: Global system → Mode system overlay (if any) → Mode rules → Project narrative.
- Implementation: `codex.sh` concatenates/feeds prompts to `codex` in that order (exact mechanism depends on codex-cli interface; well use files/flags as supported).
- Explicit: `prompts/global/` is present and used as the base of composition.
- Governance/Propagation: non-project-specific rules are folded back into global/system and templates; changes logged.
- TDD: tests are written first and required for acceptance.
- Zero Debt: no pending TODOs/deferrals; docs updated alongside code; production-ready gate on each change.
- Planning/Architecture: architecture/module map documented; implementations follow plan without unplanned refactors.
## Safety
- Guardrails:
- Refuse `run` and `new-project` inside this repo; allow only `new-mode` here.
- Refuse to overwrite files unless `--force`.
- Never execute `git push` in user projects.
## Crawl → Walk → Run
- Crawl (Phase 1 — initial MVP):
- `CodexHelper` with subcommands implemented.
- Global system location and one example mode scaffolder.
- Project scaffold: prompts, codex.yaml, codex.sh, .gitignore (runs/).
- Config precedence implemented; sandbox/full-auto pass-through.
- Binary detection and friendly error messages.
- Minimal docs: README quickstart; `docs/wrapper.md` for usage.
- Walk (Phase 2):
- `--interactive` prompts for missing values.
- Mode defaults (`defaults.yaml`) respected and merged.
- Basic tests for key flows; improved logging in `runs/`.
- Add `docs/ROADMAP.md` entries and initial MCP placeholders.
- Run (Phase 3):
- Mode/project wizards via markdown intake with validation.
- MCP integration options.
- Additional quality-of-life flags and templates.
## Acceptance Criteria (Phase 1)
- Running `CodexHelper new-mode --name Demo` inside this repo creates `modes/Demo/{mode.md,defaults.yaml}`.
- Running `CodexHelper new-project --mode Demo --name demo --path /tmp` creates a project with files listed above, without overwrites unless `--force`.
- Inside that project, `CodexHelper run --full-auto` composes prompts and calls the detected `codex` binary. It writes artifacts under `runs/<timestamp>/...`.
- Precedence works: CLI options override env, which override project config, which override mode defaults.
- Running `CodexHelper run` in this repo prints an error guiding usage.
- Project scaffold includes `AGENTS.md` copied from `templates/project/_shared/AGENTS.md`.
- `prompts/global/{system.md, system.llm.md}` exist and are included in composition.
- Governance/Propagation honored: when norms change, update `prompts/global/` and AGENTS templates; log in DevLog.
- TDD honored: a test suite (bats) covers CLI flows and guardrails; tests pass.
- Zero Debt honored: code, tests, and docs complete; no debt items remain.
- Clean Root honored: only essential files at root; scaffolding places assets under subdirectories.
- CI/Containers honored: CI runs in Gitea and locally using the same Docker Compose; containers and networks use explicit names and are cleaned up.
- Project scaffold includes `.gitea/workflows/ci.yml`, `docker/compose.yml`, `docker/test/Dockerfile`, and `scripts/test.docker.sh` copied from templates.
- Audits honored: audit script present and executed in CI; reports are recorded when performed.
## Open Items for Confirmation
- Template coverage: include `prompts/style.md` by default? (well include as optional, empty file)
- Exact prompt-passing flags to `codex-cli` (confirm once coding — will use pass-through and files as supported).
## Next Step
- On approval, I will create a concrete implementation plan at `collab/plan/01-codexhelper.md` and proceed with the Crawl phase implementation.
## Approval Checklist
Please answer inline. When all are approved, reply “Approved for Plan”.
1) Subcommands: approve `new-project`, `run`, `new-mode`? Any renames?
2) Scope: inside this repo allow only `new-mode`; outside allow `new-project` and `run`?
3) Prompts order: global system → mode system overlay (optional) → mode rules → project narrative?
4) Config format/precedence: YAML with `yq`; CLI > env > project > mode > global?
5) Safety: require `--force` to overwrite; never `git push` for user projects; outputs under `<project>/runs/<timestamp>/...`?
6) Repo layout: `CodexHelper`, `prompts/global/system.md`, `modes/<Name>/{mode.md, system.md?, defaults.yaml}`, `templates/project/<Name>/...`?
7) Project layout: `prompts/{project.md, style.md?}`, `prompts/_mode/` (read-only copies), `codex.yaml`, `codex.sh`, `.gitignore (runs/)`?
8) Include empty `prompts/style.md` by default?
9) Binary discovery: try `codex` then `codex-cli`; allow override `CODEX_BIN`?
10) Pass-through flags: `--mode`, `--prompt-file`, `--config`, `--sandbox`, `--full-auto` to underlying `codex`?
11) Block `run` and `new-project` inside this repo with a helpful error?
12) Phase 1 (Crawl) scope acceptable as listed?
13) Roadmap: add `docs/ROADMAP.md`; defer MCP integration for now?

View File

@@ -0,0 +1,9 @@
# 02 — Branching/Release — Proposal (LLM)
- Goal: Keep `main` always green and production-ready with CI protections, while developing on short-lived branches.
- Recommended model: Trunk-based. Optional `next` only for batching risky work.
- Main content: full repo (code, prompts, templates, docs). Release tags: `YYYY-MM-DD-HHMM` on `main` only.
- Protections: required checks (audit + Docker tests), PRs required, Conventional Commits, linear history/squash.
- Migration: tag baseline; create `wip/phase1`; enable protections; add docs/branching.md.
Approve by replying in the human doc with “Approved for Plan”.

View File

@@ -0,0 +1,22 @@
# 02 — Branching/Release — Proposal
Purpose: Keep `main` production-ready and clean; iterate on short-lived branches with CI protections.
## Recommendation
- Model: Trunk-based development
- `main` is always green and production-ready (zero technical debt).
- Use short-lived branches by type: `feat/*`, `fix/*`, `chore/*`, `docs/*`, `ci/*`, `refactor/*`.
- Optional `next` integration branch if batching risky work.
- Repo content on `main`: full repo (code, prompts, templates, docs). Every merge passes audits and Docker-based CI.
- Releases: tag `YYYY-MM-DD-HHMM` on `main` only.
- Protections: required checks (audit + Docker tests), PRs required, Conventional Commits, linear/squash merges.
## Migration (high level)
- Tag current baseline on `main`.
- Create `wip/phase1` from `main` and continue ongoing TDD work there.
- Enable branch protections for `main` in Gitea (required checks + PRs).
- Add `docs/branching.md` policy and link in README.
## Decision
Please reply “Approved for Plan” to proceed to the detailed branching plan.

View File

@@ -0,0 +1,21 @@
# 00 — Bootstrap — Questions (LLM)
- Remote: origin main; push enabled.
- Tagging: local time `YYYY-MM-DD-HHMM`.
- Commits: Conventional Commits.
- Codex binary: detect `codex` then `codex-cli`; allow `CODEX_BIN` override.
- Invocation defaults: user currently uses `codex --sandbox workspace-write --full-auto`; make these configurable.
- Defaults: accept codex-cli defaults for model/token/reasoning unless overridden.
- Precedence: CLI > env > project > mode > global.
- Config files: project-contained; no user home dotfiles.
- Prompts storage: in this repo — global system + mode rules (and optional mode system overlay). Projects elsewhere.
- Projects: not inside this repo; wrapper used from external project directories.
- MCP: mix of per-mode defaults + per-project; defer implementation (track in `docs/ROADMAP.md`).
- Wizards: basic for now (mode: name/desc/defaults/prompts/MCP; project: name/path/prompt/default mode/overrides).
- CLI UX: prefer subcommands; inside this repo allow only `new-mode`; outside support `new-project` and `run`.
- Outputs: write to `<project>/runs/<timestamp>/...`.
- Safety: never overwrite without `--force`; never run `git push` for user projects.
- Licensing: repo AGPLv3; user artifacts are user-licensed.
- OS/Deps: Ubuntu/Debian; bash, git, yq.
- Install: use `CodexHelper` from PATH; provide optional `bin/install.sh` to symlink.
- Copy prompts: on project scaffold, copy global/mode prompts into `prompts/_mode/` in project (read-only annotated) and compose: global → mode overlay → mode rules → project narrative.

View File

@@ -0,0 +1,236 @@
# 00 — Bootstrap — Questions
These questions guide the initial design and implementation. Please answer inline.
Process note: We will continue to add or refine questions here until you approve this questions file. Only after approval will we draft a proposal and a plan.
## Repo & workflow
1. Git remote: Should we push to an existing remote? If yes, provide the remote URL and branch (default `origin main`).
Yes. Remote is already setup, origin main works.
2. Tagging: Use `YYYY-MM-DD-HHMM` in local time or UTC? Use `tea` only for tagging/releases, or also for pushes?
local time
I'll leave it to you to utilize git/tea commands how you see fit. That's an implementation detail as far as i'm concerned.
3. Commit cadence: Any specific commit style (e.g., Conventional Commits)?
Yes Conventional Commits always.
## codex-cli wrapper
4. codex-cli path: How is `codex`/`codex-cli` invoked in your environment (command name, install path)?
Use which to figure out the path, I am not sure.
For now, I use
codex --sandbox workspace-write --full-auto
(We will need to let those options be set as well)
5. Defaults: Preferred default model, token budget, and reasoning level?
I am not sure. I've been happy with the defaults out of the box so far.
6. Config precedence: Order of overrides? (e.g., CLI flags > env vars > project config > mode config > global defaults)
yes I think so. I believe that is the common convention?
In my mind, a project config would be a complete collection of everything needed and packed into a shell script that fires
up codex and feeds it the project/mode/system prompt.
7. Config files: Desired locations/names? (e.g., `.codexrc`, `.codex/mode.yaml`, `project.yaml`)
I don't want anything in a user home directory. I want it all contained in a project.
8. Prompts storage: Where to store Global System Prompt, Mode Prompt, and Project Prompt? (proposal: `modes/<name>/system.md`, `modes/<name>/mode.md`, `projects/<name>/prompt.md`)
Right.
I don't want projects under this directory/repository. I don't want to pollute this repository with projects. They would go in a sibling directory or anywhere else the user wants them. This repository is just for the scaffolding project itself (shell script, example configs, template scaffolding for projects and modes) and of course the various modes themselves (and an example project of a resume rewriter to match to a job description).
9. MCP configuration: Expected format and location? (JSON/YAML/TOML; per-mode vs per-project)
I believe it would be a mix of per-mode (defaults) and per-project (as needed). So, for example, a software mode project at TSYS (my company) would have Cloudron/Gitea/Redmine MCP servers by default and then the project may add in language specific MCP servers. I am not sure how to handle MCP, I want to tackle that last, as it's quite complex. (Ensure you create and maintain a ROADMAP.md file in the docs direcotry).
## Wizards
10. Mode wizard fields: Minimum fields for a mode (name, description, defaults, prompts, MCP config)? Any templates you prefer?
11. Project wizard fields: Minimum fields for a project (name, path, project prompt, default mode, overrides)?
Yes I think that's fine for now.
## Execution behavior
12. Mode selection: CLI flags `--mode`, `--project`, and optional `--prompt-file` acceptable?
Hmmmm. I think just --mode. So heres my thinking... I would create and clone a new git repo somewhere in my home directory. I would have this shell script added to my path. I would go to my newly cloned repo, and I would run CodexHelper --mode SAASApp (let's say) and that would then scaffold a project of that mode? I'm struggling a bit to articulate what I want and think through the usage/implementation. I suppose maybe it would be combo of --mode and --new-project or something like that? Basically I'm tired of maintaining a library of markdown files that I cobble together in each new project I run codex in. I want a way to streamline that.
13. Non-interactive: Should wrapper fully resolve configs non-interactively by default, with an `--interactive` flag for wizard-like prompting?
Hmmm. I am not sure. I haven't fully thought through the usage modes yet.
14. Output handling: Where to log transcripts or runs? (proposal: `runs/<timestamp>/…`)
That should NOT be in this project/directory. It should be wherever the script is invoked from. If the script is invoked in this repo working directory, it should only be for creating new modes. (or of course running unit tests etc)
15. Safety: Any commands that must never be executed without confirmation?
Hmmm. I am not sure. I haven't fully thought through the usage modes yet. Open to suggestions/trying things out.
## Misc
16. Licensing/headers: Any repo-specific requirements beyond the existing LICENSE?
I want to clearly state that this repo is AGPLv3 (code/prompts) but NOT anything the user writes in their project specific prompt and any code they generate. Basically the "code" (shell script/prompt files) in this repo is AGPLv3 but the "data" (any artifacts they write or codex creates with them) is up to them to license.
17. Supported OS/shells: Target bash/zsh on macOS/Linux, anything else?
Lets say Ubuntu 22.04/Debian 12 or later.
## Followup 2025-17-09-14:21
### Wrapper naming & install
1. Wrapper name: prefer `codex-helper` or `CodexHelper`? Install path (e.g., `~/bin`)?
CodexHelper please
This will not be "installed". It will be cloned , the CodexHelper shell script added to the users path. The CodexHelper is only an entrypoint and wrapper around codex-cli (CodexHelper should have a bootstrap function to ensure codex-cli is actually installed of course). The CodexHelper script will be called from within a project directory somewhere else on the filesystem. It may or may not be a git repository working directory.
2. Binary discovery: try `which codex` first, then `codex-cli`? Allow override via `CODEX_BIN` env var?
Sure.
### Modes and templates
3. Repo layout: store modes under `modes/<name>/` with `system.md`, `mode.md`, `defaults.yaml`? OK?
Yes. However the system prompt is shared across all modes. It will be about a dozen rules or so that I want applied to all of my projects.
Perhaps we should allow a mode specific system prompt as well? I don't know enough about how prompts are chained or stacked to fully
understand the implications.
Basically I want a base set of global rules, a mode set of rules and then a project prompt (which won't be rules per se (well maybe coding styles or something)) but more of a narrative/descriptive set of material telling codex WHAT to do (not so much how to do it)
4. Project scaffolding: create templates under `templates/project/<mode>/...` and generate into user-specified target path? OK?
I am not sure what this means? Give me some examples?
5. Example project: include only one example (resume rewriter). Where should we place the example template in this repo?
Actually forget all about the example project. I'm going to do that in a different repository. I want this project/repo to be purely code/prompts.
### Project structure & config
6. Config format: YAML vs JSON vs TOML? Preference? (YAML easier for markdown-heavy prompts.)
7. Single file vs split: prefer `project.yaml` in project root, or split into `prompts/` + `codex.yaml`?
8. Precedence confirm: CLI > env > project > mode > global defaults — confirm this exact order?
9. Entrypoint script: generate `codex.sh` in project root that resolves config and runs `codex`? Name OK?
I think that all looks good. I'll leave it to your discretion. I need to get a "feel" for the usage and tweak as we go.
### CLI UX
10. Subcommands: propose `new-project`, `new-mode`, and `run`. Example:
- `codex-helper new-project --mode SAASApp --name my-app --path ~/dev/my-app`
- `codex-helper new-mode --name SAASApp`
- `codex-helper run` (inside a project dir)
Approve?
11. Flags: always accept `--mode`, `--prompt-file`, `--config`, `--sandbox`, `--full-auto` to pass through to codex. Anything else?
12. Non-interactive default: default non-interactive; add `--interactive` to prompt for missing values. Approve?
Yes I think that all looks good.
### Outputs, safety, and licensing
13. Runs directory: write transcripts/logs to `<project>/runs/<timestamp>/...`. Approve?
Well remember, we don't allow the script to run from inside the repo checkout directory except to create new modes.
14. Safety: default to no destructive actions; require `--force` to overwrite existing files; never run `git push` for user projects. Approve and add anything else?
User projects will never be created in this repo.
15. Dependencies: are `bash`, `git`, and one of `jq` (JSON) or `yq` (YAML) acceptable? Preference?
Sure. I suppose we should settle on either json or yaml? Supporting both seems like more work?
16. Licensing in generated projects: include no default LICENSE, or include a template with TODO? Preference?
The user will pick a license. We won't be invovled.
### Roadmap
17. We will add `docs/ROADMAP.md` and defer MCP integration. Any additional roadmap items you want listed now?
No
## Followup 2025-17-09-14:33
### CLI UX and workflow
1. Subcommands vs flags-only: prefer simple flags (e.g., `CodexHelper --mode SAASApp --new-project`) or explicit subcommands (`CodexHelper new-project --mode SAASApp`)? Please pick one.
What are the tradeoffs? I don't really have a strong opinion either way. What do you think is the better UX? I think the subcommands looks a bit nicer.
2. Project creation flow: confirm that `CodexHelper` runs from any project dir outside this repo to scaffold project files for a chosen mode; this repo is only for modes and the wrapper. Correct?
That iscorrect. Modes, wrapper, prompts to be explicit. (Of course a mode would have prompts and (eventaully) MCP config templates etc). I think we are on the same page. Now, CodexHelper would run inside the repo to create a new mode. That would be the only command supported when running inside the repo (it would scaffold a new mode for bootstrap via filling out markdown intake files). 99.9% of the CodexHelper usage will be outside of the repo, yes.
### Templates and scaffolding
3. Examples for project scaffolding (pick what you want generated initially):
- prompts/: `project.md` (narrative), optional `style.md`
- config: `codex.yaml` (mode selection, settings, MCP placeholders)
- helper: `codex.sh` entrypoint that resolves config and runs `codex`
- runs/: created on first run, ignored by VCS
Keep/delete/adjust which of these?
All of that looks good. What about the system prompt/mode prompt? And I presume the codex.sh invoking of codex would also automatically pass in project.md (and somehow the system/mode prompt as well)? Can the system/mode prompt be copied (read only) to the project directory? THis would allow the entire thing to be self contained/commited to git etc? And the read only bit could easily be removed if the user wants to edit the system/mode prompt.
### Prompts composition
4. Confirm stacking order: Global system rules → Mode rules → Project narrative prompt. OK?
Yes. That is correct.
5. Locations proposal: `prompts/global/system.md` (repo-wide), `modes/<name>/system.md` (optional overlay), `modes/<name>/mode.md` (mode rules), project `prompts/project.md`. Approve?
What would the optional overlay be for? Tell me more about that?
project.md wouldn't be in this repo (or is that a blank placeholder file (or maybe a one line "put your instructions here" or something)) that gets copied into the project directory during bootstrap?
### Config and tooling
6. Format/tooling: choose YAML + `yq` as the single supported format/tool. Approve?
Yes
## Explainers 2025-17-09-14:52
- Subcommands vs flags-only (tradeoffs):
- Subcommands: clearer discoverability (`CodexHelper new-project|new-mode|run`), better `--help` per action, easier future growth. Flags-only keeps one surface but is harder to parse and extend. Recommend subcommands; flag-only aliases can follow later if wanted.
- Project scaffolding examples:
- In project: `prompts/project.md` (narrative), optional `prompts/style.md` (coding/style), `codex.yaml` (mode/config/MCP placeholders), `codex.sh` (entrypoint). `runs/` created on first run and ignored by VCS.
- `codex.sh` composes prompts: global system → mode rules → project narrative; passes them to `codex` with settings.
- Mode/system prompt copies:
- Copy global/mode prompts into `prompts/_mode/` in the project as read-only templates (annotated header). Project becomes self-contained; users may edit if desired.
- Optional mode-specific system overlay:
- For modes that need extra or tweaked system-level rules, include `modes/<name>/system.md` merged before mode rules.
- `project.md` here vs user projects:
- This repo keeps a template (e.g., `templates/project/<mode>/prompts/project.md`) which bootstrap copies to user projects; users then author real content there.
7. Precedence final confirm: CLI > env > project > mode > global defaults. Approve?
Yes
8. Binary detection: detect `codex` then `codex-cli`, override with `CODEX_BIN`. On missing, print instructions; no auto-install. Approve?
Yes
### Outputs and safety
9. Runs location: always `<cwd>/runs/<timestamp>/...` (never in this repo unless creating modes). Approve?
Yes
10. Safety: never overwrite without `--force`; never run `git push` in user projects. Anything else to lock down?
Cant think of anything
### Install convenience
11. Provide optional `bin/install.sh` to symlink `CodexHelper` into `~/bin` (no sudo). Include or skip?
Yes

View File

@@ -0,0 +1,20 @@
# 02 — Branching/Release — Confirm (LLM)
- Goals: top 3 drivers for change? [ ]
- Stability: main = always green release-ready OR docs-only? [ ]
- Consumption: what must be on main for bootstrap? [ ]
- Choose model:
- Trunk-based (main green; short-lived branches) [ ]
- WIP branch (main release-only; WIPhax/wip/*) [ ]
- GitFlow (main/develop/release/hotfix) [ ]
- Repo content on main: A full repo [ ] / B no code/prompts [ ] / C minimal bootstrap [ ]
- If B/C: where do code/prompts live? naming? [ ]
- Protections: require CI checks on main [ ]; PR reviews [ ]; Conventional Commits [ ]; tags only for release-ready [ ]
- Migration: baseline commit/tag [ ]; create branches [ ]; update CI protections [ ]; add docs/branching.md [ ]
Final: Reply “Approved for Branching Plan” with choices to proceed.

View File

@@ -0,0 +1,69 @@
# 02 — Branching/Release — Questions
Purpose: Align on a clean, sustainable branch and release strategy before any changes. We will not implement until you approve.
Context: You suggested moving active work to a `WIPhax` branch and keeping `main` limited to non-code assets (docs/collab/.gitea). Below are options and tradeoffs to decide together.
## Goals & Constraints
1) Primary goals: What are the top 3 goals driving this change? (e.g., keep `main` always pristine, minimize merge noise, avoid half-baked code on main, simplify consumption by other projects, etc.)
main pristine
avoid half-baked code on main
simplify consumption by other projects
2) Stability bar: Should `main` be “always green + release-ready” with protected branch/required CI? Or “docs-only” as you proposed?
"always green + release ready"
3) Consumption: Will external automation/scripts rely on cloning `main` to bootstrap? If yes, what assets must be present on `main` (templates, prompts, wrapper) to keep bootstrapping simple?
No. I don't believe this will ever be automatically cloned to bootstrap. I expect that to be only done by a human. I can't control what people do of course, it's a public repo.
## Branching Models (pick one or adjust)
4) Trunk-based (recommended):
- `main` = always green, release-ready. All commits pass CI (Docker) and TDD.
- Work happens on short-lived feature branches `feat/*`, `fix/*` merged via PR.
- Optional long-lived integration branch `next` for batching risky changes.
5) WIP branch variant:
- `main` = release-ready only; heavy ongoing work on `WIPhax` (or `wip/*`), merged back via PR when green.
- Risk: drift between `WIPhax` and `main`, elevated merge pain if long-lived.
6) GitFlow:
- `main` for releases; `develop` for integration; feature branches; release/hotfix branches.
- Heavier process; likely overkill unless multiple contributors and scheduled releases.
Trunk based sounds perfect
## Repo Content Policy
7) What exactly belongs on `main`? Options:
- A) Full repo (code + prompts + templates + docs) — but always green.
- B) Everything except code/prompts (your suggestion) — use branches/tags for code.
- C) Minimal bootstrap subset (AGENTS seeds, prompts/global, templates/_shared) + docs.
Please choose and list mandatory directories for `main`.
A
8) If B or C: where do code/prompts live (branch names/tags)? How will downstream projects fetch them reliably?
## CI/Gitea Protections
9) Protect `main` with required checks (Docker tests) and linear history? Approve?
yes I approve
10) Require PR reviews and enforce Conventional Commits? Approve?
Yes I approve
11) Tagging: continue `YYYY-MM-DD-HHMM`. Should `main` tags correspond only to release-ready points?
Hmmm.... I was using tags/releases as a kind of "hack" or "snapshots" and that's not the practice I want to have. Yes the tags should only be release-ready points.
## Migration Plan (once we choose)
12) Baseline selection: pick commit/tag for the new `main` baseline.
13) Branch ops: create `WIPhax`/`next`/`develop` as chosen; move ongoing TDD work there.
14) CI updates: confirm branch protections and required checks in Gitea.
15) Docs: add `docs/branching.md` describing the policy; update README.
Do you need anything from me for this section? It's statements not questions, but that plan looks good to me.
## Decision
16) Please pick one model (4/5/6) and option (7 A/B/C), then reply “Approved for Branching Plan” (or edit inline). Ill draft `collab/plan/02-branching.md` for review.

19
docker/compose.yml Normal file
View File

@@ -0,0 +1,19 @@
name: codexhelper
services:
tests:
build:
context: ..
dockerfile: docker/test/Dockerfile
container_name: codexhelper-tests
working_dir: /work
volumes:
- ..:/work:Z
command: ["/bin/bash", "-lc", "scripts/test.sh"]
networks:
- codexhelper-net
networks:
codexhelper-net:
name: codexhelper-net

11
docker/test/Dockerfile Normal file
View File

@@ -0,0 +1,11 @@
FROM debian:bookworm-slim
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update \
&& apt-get install -y --no-install-recommends \
ca-certificates git bash curl jq yq \
bats \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /work

34
docs/architecture.md Normal file
View File

@@ -0,0 +1,34 @@
# CodexHelper — Architecture (Phase 1)
Overview
- Goal: Bash wrapper around `codex`/`codex-cli` with modes, project scaffolding, prompt composition, config precedence, and safety.
- Constraints: TDD, zero technical debt, plan-first, clean root, CI via Gitea with local Docker parity.
Modules
- CLI Entrypoint (`CodexHelper`)
- Subcommands: `new-mode` (repo-only), `new-project` (outside repo), `run` (outside repo)
- Guardrails: detect helper repo by structure; block disallowed subcommands
- Binary Detection: `CODEX_BIN` > `codex` > `codex-cli`
- Flag Pass-through: `--mode`, `--prompt-file`, `--config`, `--sandbox`, `--full-auto`, `--`
- Scaffolding
- Modes: `modes/<Name>/{mode.md, defaults.yaml, system.md?}` with intake hints
- Projects: `AGENTS.md`, `prompts/{project.md,style.md?}`, `prompts/_mode/` (copies of global/mode prompts), `codex.yaml`, `codex.sh`, `.gitignore`, CI/containers templates
- Run Engine
- Validate project layout
- Compose prompts (global system → mode system? → mode rules → project narrative)
- Invoke `$CODEX_BIN` with pass-through flags; write artifacts under `runs/<ts>/`
- Config
- YAML via `yq`: global defaults < mode defaults < project config < ENV < CLI
Cross-cutting
- Tests: `tests/` via bats or fallback; Docker Compose runner for local parity; Gitea Actions for CI
- Docs: `README.md`, `docs/wrapper.md`, `docs/architecture.md`, DevLogs
- Governance: propagation updates applied to prompts/global and AGENTS templates
Assumptions
- `yq` available in containers; host only orchestrates Docker and git/tea.
- codex auth may require host mounts; handled via project `codex.sh` composition.

View File

@@ -0,0 +1,29 @@
# Audit — 2025-09-17
Summary
- Scope: Repo structure, governance compliance, plan alignment, CI/containers, TDD, zero-debt.
- Status: Mostly compliant; a few gaps noted with fixes proposed or applied.
Findings
- Governance
- One-way Q→P→Plan: compliant.
- Read `.llm.md`/write both: compliant in artifacts; continue practice.
- TDD: present; tests for CLI/guardrails/new-mode exist; proceed to cover remaining milestones.
- Zero debt: generally compliant; architecture doc added now to satisfy plan; keep docs/tests in lockstep.
- Clean root: compliant; marker removed; heuristic detection in place.
- Planning/architecture: docs/architecture.md added; maintain ADRs if decisions evolve.
- CI/containers: Gitea workflow + Docker Compose present; local parity script present.
- Repo Structure
- Organized under `collab/`, `docs/`, `prompts/`, `modes/`, `templates/`, `scripts/`, `meta/`, `.gitea/` — clean.
- Scaffolding Templates
- Added project CI/Docker templates and AGENTS.md. Missing: project `.gitignore` and `scripts/test.sh` template (recommended; add).
- Tests
- Repo tests pass (internal runner). Add Docker test run to CI already configured.
- Open Work vs Plan
- Pending: `new-project`, `run`, config precedence (`yq`), copying templates, `.gitignore` template, project scripts/test.sh.
Actions
- Add templates/project/_shared/{.gitignore,scripts/test.sh} [recommended ASAP].
- Implement remaining milestones via TDD; expand tests accordingly.
- Keep DevLogs updated for each change.

View File

@@ -0,0 +1,34 @@
# Audit — 2025-09-17
Scope
- Full audit of repository against governance rules, proposal/plan, and delivered code.
Summary
- Compliance is strong across governance (TDD, zero-debt, planning, clean root, CI/containers). Gaps are minor and fixable now.
Findings
- Governance compliance
- One-way Questions→Proposal→Plan process is followed; confirmations consolidated into the proposal.
- `.llm.md`-first reading and dual-write artifacts are present and used.
- TDD in effect (tests for CLI/guardrails/new-mode). Continue test-first for remaining milestones.
- Zero technical debt emphasized; architecture doc added to meet plan; docs kept current.
- Clean root enforced; marker removed; heuristic repo detection implemented and tested.
- Planning/architecture documented in `docs/architecture.md`; maintain ADRs if decisions change.
- CI/containers aligned with Gitea and local parity via Docker Compose; names explicit and cleanup performed.
- Structure
- Root remains minimal. Subdirectories are coherent: `collab/`, `docs/`, `prompts/`, `modes/`, `templates/`, `scripts/`, `meta/`, `.gitea/`.
- Templates
- Project templates include AGENTS.md and CI/Docker artifacts. Missing `.gitignore` and `scripts/test.sh` template — add now.
- Tests
- Repo tests pass locally (internal runner). Docker-based runner available (`scripts/test.docker.sh`). CI workflow uses the same compose.
- Open vs Plan
- Not yet implemented: `new-project`, `run`, YAML precedence (`yq`), project `.gitignore`, project scripts/test.sh, copying mode/global prompts.
Recommendations (immediate)
- Add `templates/project/_shared/.gitignore` with `runs/` and common ignores.
- Add `templates/project/_shared/scripts/test.sh` mirroring repo test runner.
- Proceed with TDD for remaining milestones; update docs/DevLogs at each step.
Conclusion
- The project is on track and adheres to governance. Address the small template gaps and continue TDD implementation.

200
docs/devlog/DEVLOG_HUMAN.md Normal file
View File

@@ -0,0 +1,200 @@
# Development Log (Human Readable)
Date: 2025-09-17 08:55 (UTC)
Summary:
- Bootstrapped collaboration scaffolding based on SeedPrompt.md.
- Created dev logs (LLM-optimized and human-readable) and a QUESTIONS.md file.
Details:
- Rationale: Establish clear, file-based collaboration channels (logs + questions) with minimal noise in chat.
- Scope: No functional code yet; this is setup to enable fast iteration.
Next Steps:
- Collect answers in `collab/questions/00-bootstrap.md`.
- With clarifications, propose initial design and plan for the wrapper script (crawl phase).
Notes:
- Tagging a release and using `tea` is deferred until we have a first runnable wrapper or as directed.
---
Date: 2025-09-17 09:05 (UTC)
Summary:
- Introduced `collab/` directory; moved QUESTIONS into `collab/questions/00-bootstrap.md`.
- Added `AGENTS.md`; appended housekeeping Addendum to `SeedPrompt.md`.
Details:
- Establishes consistent file-based collaboration area and naming scheme.
Next Steps:
- Await answers to bootstrap questions, then proceed after approval.
---
Date: 2025-09-17 14:52 (UTC)
Summary:
- Adjusted questions doc to replace prior “Answers/Explainers” with an “Explainers” section focused on responding to back-questions.
Next Steps:
- Await your confirmation or additional edits; then, on approval, draft proposal and plan.
---
Date: 2025-09-17 15:00 (UTC)
Summary:
- Adopted token/context hygiene policy; moved DevLog under docs/.
Details:
- Updated AGENTS.md and SeedPrompt addendum to emphasize filesystem-first collaboration and minimal chat.
Next Steps:
- Continue logging details here, keep chat concise.
---
Date: 2025-09-17 15:20 (UTC)
Summary:
- Oriented to the repository layout and prior collaboration artifacts (00 bootstrap questions and 01 proposal).
- Created 01-round confirmation questions to secure explicit approval before planning.
Details:
- Added `collab/questions/01-codexhelper.md` and `collab/questions/01-codexhelper.llm.md` focused on confirming the proposal and minor options.
- Will not create a plan until explicitly approved per AGENTS.md sequencing rules.
Next Steps:
- Await approval in `collab/questions/01-codexhelper.md`.
- If approved, draft `collab/plan/01-codexhelper.md` and begin Phase 1 implementation.
---
Date: 2025-09-17 15:28 (UTC)
Summary:
- Adopted one-way progression (no returning to prior step after approval) and in-place editing per step file.
- Consolidated confirmation items into the proposal; removed redundant questions round.
Details:
- Updated AGENTS.md sequencing rules to codify one-way progression and `.llm.md` read policy.
- Added approval checklist to `collab/proposals/01-codexhelper.md` and `.llm.md`.
- Removed `collab/questions/01-codexhelper.*` to avoid back-stepping.
Next Steps:
- Await proposal approval in `collab/proposals/01-codexhelper.md`.
- Then create `collab/plan/01-codexhelper.md`.
---
Date: 2025-09-17 15:36 (UTC)
Summary:
- Captured the global system prompt directly (one-time exception) per request and aligned AGENTS.md to reference it.
Details:
- Added `prompts/global/system.md` and `prompts/global/system.llm.md`.
- Updated AGENTS.md to note the canonical system rules location and reinforce `.llm.md`-only reading policy and one-way progression.
Next Steps:
- Use these artifacts for all subsequent work and generated projects.
---
Date: 2025-09-17 15:42 (UTC)
Summary:
- Added seed AGENTS templates and a project AGENTS template for scaffolding.
Details:
- Created `meta/AGENTS.seed.md` and `meta/AGENTS.seed.llm.md` as bootstrap references.
- Created `templates/project/_shared/AGENTS.md` to be copied into new projects.
- Updated AGENTS.md to reference the seed templates.
Next Steps:
- When implementing `new-project`, copy `templates/project/_shared/AGENTS.md` into the project root.
---
Date: 2025-09-17 15:48 (UTC)
Summary:
- Folded `meta/` seed AGENTS and `prompts/global/` into the proposal so the upcoming plan includes them.
Details:
- Updated `collab/proposals/01-codexhelper.md` and `.llm.md` to explicitly list `meta/AGENTS.seed.*`, `templates/project/_shared/AGENTS.md`, and `prompts/global/` in repo/project layouts and acceptance criteria.
Next Steps:
- Await proposal approval; then codify in `collab/plan/01-codexhelper.md`.
---
Date: 2025-09-17 15:55 (UTC)
Summary:
- Added an explicit governance/propagation rule so that reusable workflow changes are folded into the global system prompt and AGENTS templates and reflected in proposal/plan.
Details:
- Updated `prompts/global/system.{md,llm.md}` with a Governance and Propagation section.
- Updated `meta/AGENTS.seed.*` and `templates/project/_shared/AGENTS.md` to include propagation guidance.
- Reflected this rule in `collab/proposals/01-codexhelper.{md,llm.md}`.
Next Steps:
- Apply this propagation practice for future non-project-specific instructions.
---
Date: 2025-09-17 16:00 (UTC)
Summary:
- Committed and pushed all recent changes; verified local is in sync with remote.
Details:
- Conventional Commits used; pushed to `origin main`.
- Verified `HEAD` equals `origin/main` and working tree is clean.
Next Steps:
- Await proposal approval; then draft `collab/plan/01-codexhelper.md`.
---
Date: 2025-09-17 16:05 (UTC)
Summary:
- Created Phase 1 implementation plan for CodexHelper.
Details:
- Added `collab/plan/01-codexhelper.md` and `.llm.md` with milestones, deliverables, and acceptance criteria aligned to the approved proposal.
Next Steps:
- Await plan review/approval; then start implementation.
---
Date: 2025-09-17 16:12 (UTC)
Summary:
- Incorporated TDD as a governance rule with full unit/integration tests for all features in this repo and generated projects.
Details:
- Updated `prompts/global/system.{md,llm.md}`, `meta/AGENTS.seed.*`, and `templates/project/_shared/AGENTS.md` to mandate TDD.
- Amended the proposal and plan to include TDD milestones and test coverage acceptance criteria.
Next Steps:
- Execute the plan using TDD, starting with test harness setup and failing tests.
---
Date: 2025-09-17 16:24 (UTC)
Summary:
- Added governance: zero technical debt and production-ready at all times (safety first, speed second) for this and generated projects.
Details:
- Updated system prompts and AGENTS templates to mandate zero-debt and remove any doc/test deferrals.
- Updated proposal and plan to include this rule and acceptance criteria.
Next Steps:
- Maintain zero-debt gate during implementation; no merges without tests and docs.

254
docs/devlog/DEVLOG_LLM.md Normal file
View File

@@ -0,0 +1,254 @@
# Dev Log (LLM-Optimized)
This log is concise and structured for quick machine parsing and summarization. One entry per session/change.
## 2025-09-17T08:55Z
- context: Initialized collaboration per SeedPrompt.md
- actions:
- Added `docs/devlog/DEVLOG_LLM.md` and `docs/devlog/DEVLOG_HUMAN.md`
- Added `collab/questions/00-bootstrap.md` (moved from root)
- decisions:
- Defer tagging a release until first runnable wrapper exists
- next:
- Await answers in `collab/questions/00-bootstrap.md`
- Draft proposal and implementation plan once clarified
## 2025-09-17T09:05Z
- context: Housekeeping structure introduced
- actions:
- Created `collab/` directory and moved questions to `collab/questions/00-bootstrap.md`
- Added `AGENTS.md` and SeedPrompt addendum
- decisions:
- Adopt per-type subdirectories inside `collab/`
- next:
- Await answers in `collab/questions/00-bootstrap.md`
- Then proceed post-approval
## 2025-09-17T14:52Z
- context: Clarified explainers vs user answers
- actions:
- Replaced prior answers section with targeted Explainers
- next:
- Await approval to proceed
## 2025-09-17T15:00Z
- context: Token hygiene + devlog location
- actions:
- Adopted token/context hygiene rules in AGENTS.md and SeedPrompt
- Moved DevLog under `docs/devlog/`
- next:
- Keep chat minimal; log details here
## 2025-09-17T15:05Z
- context: Move devlog under docs; update references
- actions:
- Updated AGENTS.md, SeedPrompt.md to point to `docs/devlog/`
- Removed old `devlog/` files
- next:
- Continue detailed logging here; keep chat terse
## 2025-09-17T15:10Z
- context: Strict chat output policy adopted
- actions:
- Added Chat Output Policy to AGENTS.md and SeedPrompt.md (five-line max; default message format; no diffs in chat)
- next:
- Use filesystem-first workflow; keep chat to update notices
## 2025-09-17T15:12Z
- context: Refined chat announcements scope
- actions:
- Limited chat announcements to collab/questions, collab/proposals, collab/plan only
- next:
- Announce only those; log everything else here
\n+## 2025-09-17T15:20Z
- context: Oriented to existing questions/proposal and prepared to proceed
- actions:
- Added `collab/questions/01-codexhelper.md` and `.llm.md` to confirm proposal acceptance
- decisions:
- Defer plan creation until explicit "Approved for Plan"
- next:
- Await responses in `collab/questions/01-codexhelper.md`
- On approval, create `collab/plan/01-codexhelper.md` and start implementation
## 2025-09-17T15:28Z
- context: One-way progression clarified; avoid back-stepping
- actions:
- Updated AGENTS.md with one-way progression and in-place editing rules
- Moved confirmation checklist into `collab/proposals/01-codexhelper.{md,llm.md}`
- Removed `collab/questions/01-codexhelper.*`
- next:
- Await proposal approval in `collab/proposals/01-codexhelper.md`
- Then draft `collab/plan/01-codexhelper.md`
## 2025-09-17T15:36Z
- context: One-time direct capture of global system prompt per user instruction
- actions:
- Added `prompts/global/system.md` and `prompts/global/system.llm.md`
- Updated AGENTS.md to reference and align with the global system prompt
- decisions:
- System prompt will govern agent behavior across projects; `.llm.md` used for intake, both siblings written
- next:
- Use these artifacts going forward; keep them in sync
## 2025-09-17T15:42Z
- context: Seed AGENTS templates requested for bootstrap and project scaffolding
- actions:
- Added `meta/AGENTS.seed.md` and `meta/AGENTS.seed.llm.md`
- Added `templates/project/_shared/AGENTS.md` for project scaffolding
- Updated AGENTS.md to reference the seed templates
- next:
- Include the project AGENTS.md when implementing scaffolding
## 2025-09-17T15:48Z
- context: Folded meta and prompts/global into proposal so plan will include them
- actions:
- Updated `collab/proposals/01-codexhelper.{md,llm.md}` to explicitly list `meta/` seeds, `templates/project/_shared/AGENTS.md`, and `prompts/global/`
- Added acceptance criteria ensuring AGENTS.md is copied and prompts/global is used
- next:
- Await proposal approval; then reflect these in the plan
## 2025-09-17T15:55Z
- context: Global propagation rule requested for process adjustments across projects
- actions:
- Added Governance/Propagation sections to `prompts/global/system.{md,llm.md}`
- Updated seed and project AGENTS templates to include propagation guidance
- Reflected governance/propagation in proposal files
- next:
- Use this rule for future non-project-specific changes
## 2025-09-17T16:00Z
- context: Commit and push requested; ensure clean sync
- actions:
- Committed all staged changes with Conventional Commits
- Pushed to `origin main`
- Verified local `HEAD` matches `origin/main` and working tree is clean
- result:
- HEAD: 0625682
## 2025-09-17T16:05Z
- context: Proposal approved; creating implementation plan
- actions:
- Added `collab/plan/01-codexhelper.md` and `.llm.md` with milestones, deliverables, and acceptance criteria
- next:
- Await plan review/approval; then implement per milestones
## 2025-09-17T16:12Z
- context: Governance update — adopt TDD and full unit tests across this repo and generated projects
- actions:
- Updated global system prompt and seed/project AGENTS templates to encode TDD requirement
- Amended proposal and plan to include TDD milestones and acceptance criteria
- next:
- Proceed with TDD in implementation; scaffold tests first
## 2025-09-17T16:18Z
- context: Compressed timeline — complete Phase 1 in ~8 hours
- actions:
- Updated plan with hour-by-hour accelerated timeline and deferral notes
- next:
- Begin implementation immediately upon plan approval
## 2025-09-17T16:24Z
- context: Governance update — zero technical debt, production-ready always (safety first)
- actions:
- Updated global system prompt and seed/project AGENTS templates with zero-debt rule
- Amended proposal and plan to require docs/tests with every feature; removed any doc deferrals
- next:
- Enforce zero-debt gate throughout implementation
## 2025-09-17T16:30Z
- context: Governance update — plan ahead and maintain global architecture; avoid refactors
- actions:
- Updated system prompts and AGENTS templates to encode planning/architecture rule
- Updated proposal/plan to add architecture/module map deliverable and acceptance
- next:
- Add `docs/architecture.md` early in implementation per plan
## 2025-09-17T16:38Z
- context: Root cleanliness governance and marker removal
- actions:
- Added clean-root rule to system prompts and AGENTS templates
- Removed `.codexhelper-repo`; replaced guard detection with repo-structure heuristic
- Updated CLI guardrail tests accordingly
- next:
- Keep root minimal going forward; store assets under subdirectories
## 2025-09-17T16:50Z
- context: CI/Containers governance (Gitea + Docker) and local parity
- actions:
- Added `.gitea/workflows/ci.yml` using Docker Compose
- Added `docker/compose.yml` and `docker/test/Dockerfile` with explicit names and cleanup flow
- Added `scripts/test.docker.sh` wrapper
- Propagated CI/containers rules to system prompts and AGENTS templates; updated proposal
- next:
- Ensure future features include containerized workflows and CI updates
## 2025-09-17T17:00Z
- context: Project scaffolding to include Gitea workflow and Docker artifacts
- actions:
- Added project templates: `.gitea/workflows/ci.yml`, `docker/compose.yml`, `docker/test/Dockerfile`, `scripts/test.docker.sh`
- Updated proposal and plan to require these in generated projects
- next:
- Implement new-project scaffolder to copy these templates
## 2025-09-17T17:08Z
- context: Full repository audit and immediate fixes for minor gaps
- actions:
- Added `docs/audits/2025-09-17-audit.{md,llm.md}` with findings and actions
- Added `docs/architecture.md` per plan
- Added missing project templates: `.gitignore` and `scripts/test.sh`
- next:
- Proceed with TDD to implement new-project and run
## 2025-09-17T17:12Z
- context: Branching/release strategy discussion opened — no changes yet
- actions:
- Added `collab/questions/02-branching.{md,llm.md}` with options/tradeoffs for `main` vs `WIPhax` and protection rules
- next:
- Await answers; then draft a branching plan for approval before any branch changes
## 2025-09-17T17:18Z
- context: Implement audit recommendations; add .gitignore and audit governance
- actions:
- Added scripts/audit.sh and CI audit step; updated project templates to include audit
- Updated global/system prompts and AGENTS templates with .gitignore housekeeping and regular audits policy
- Updated proposal/plan/docs to reflect audits
- next:
- Continue TDD implementation; run audits before any release tags
## 2025-09-17T17:22Z
- context: Branching plan drafted after approval (no changes applied yet)
- actions:
- Added `collab/plan/02-branching.md` and `.llm.md` choosing trunk-based model with protected `main`, short-lived branches, and migration steps
- next:
- Await plan approval; then execute branch creation/protections
## 2025-09-17T17:28Z
- context: Corrected sequencing slip (plan before proposal) and hardened governance
- actions:
- Added `collab/proposals/02-branching.{md,llm.md}` for formal approval; marked plan as pending
- Strengthened system prompts and AGENTS templates with strict approval gates and exact phrases
- Enhanced audit script to check sequencing gates and warn when pending
- next:
- Await “Approved for Plan” on 02-branching proposal before executing the plan
## 2025-09-17T17:34Z
- context: Silence chat streaming of file contents/diffs
- actions:
- Strengthened system prompts and templates with “Quiet Shell/No Streaming” rules
- Added audit advisory to flag usage of `cat`/`sed -n` in scripts
- next:
- Avoid printing file contents via shell; log details to DevLog when needed
## 2025-09-17T17:40Z
- context: Quiet is now mandatory (no toggle)
- actions:
- Updated system prompts and AGENTS templates to state quiet is required
- next:
- Continue with quiet operations and filesystem-first logging
## 2025-09-17T16:34Z
- context: Quiet tooling wrapper added; tool.log policy established
- actions:
- Added scripts/toolwrap.sh for quiet execution and failure logging to docs/devlog/tool.log
- Updated system prompts and AGENTS templates to use tool.log
- next:
- Use toolwrap for host-side orchestration commands to keep chat silent

5
docs/devlog/tool.log Normal file
View File

@@ -0,0 +1,5 @@
2025-09-17T16:40:06Z FAILURE: git add -A
--- STDOUT ---
--- STDERR ---
./scripts/toolwrap.sh: line 21: {git: command not found
--------------

23
docs/wrapper.md Normal file
View File

@@ -0,0 +1,23 @@
# CodexHelper Wrapper — Usage and Design (Phase 1)
Overview
- CodexHelper wraps `codex`/`codex-cli` to provide modes, project scaffolding, and prompt composition.
- Governance: TDD, zero technical debt, plan-first via Questions → Proposal → Plan, production-ready always.
Status (Phase 1 in progress)
- Implemented: `new-mode` scaffolder (repo-only), CLI skeleton, guardrails.
- Pending (per plan): `new-project`, `run`, config precedence (YAML+yq).
- CI/Containers: Gitea Actions workflow in `.gitea/workflows/ci.yml`; local parity via `docker/compose.yml`.
CLI
- Help: `./CodexHelper --help`
- Repo-only: `./CodexHelper new-mode --name <ModeName> [--force]`
- Outside-repo (pending): `CodexHelper new-project --mode <ModeName> --name <project-name> --path <dir> [--force]`
- Outside-repo (pending): `CodexHelper run [--mode <ModeName>] [--prompt-file <file>] [--config <file>] [--sandbox <mode>] [--full-auto]`
Development
- Tests: run `scripts/test.sh` (uses bats if available, falls back to internal runner).
- Docker tests: `scripts/test.docker.sh` runs the same suite via Docker Compose.
- Audit: run `scripts/audit.sh` for governance/structure checks; CI runs it too.
- Follow TDD: write failing tests first, make them pass, refactor.
- Keep `docs/architecture.md` and README up to date as features land.

27
meta/AGENTS.seed.llm.md Normal file
View File

@@ -0,0 +1,27 @@
# AGENTS (Seed, LLM)
- One-way workflow: questions → proposal → plan → implement; no backsteps after approval.
- Gates: human `.md` must include exact phrases — Questions: "Approved for Proposal"; Proposal: "Approved for Plan"; Plan: "Approved to Implement".
- Read `.llm.md` only; write both `.md` and `.llm.md` siblings for collab artifacts.
- Chat ≤5 lines; default “Updated <filepath>…”; no diffs; announce only collab file changes; log details in `docs/devlog/`.
- Quiet shell: avoid `cat`/`sed` outputs; use silent checks; log details to DevLog files.
- Quiet is mandatory (no toggle) for this tool.
- Tool logging: use quiet wrapper; log to `docs/devlog/tool.log` on failures; no chat output.
- Keep changes minimal and focused; adopt TDD (tests first); require unit/integration tests for all features; consistent style.
- Git: Conventional Commits; branch `main`; optional tags `YYYY-MM-DD-HHMM`.
- Tools: file-first; use `rg`; read ≤250 lines; respect sandbox/approvals; preface grouped commands.
- Prompts/config (if applicable): YAML+yq; precedence CLI>ENV>project>mode>global; prompts order global→mode-system?→mode→project; outputs to `runs/<ts>/`; `--force` to overwrite; never `git push`.
- Governance: For reusable rules, update system prompt and AGENTS templates; keep them aligned; log in DevLog.
- Zero Technical Debt: Safety first; no technical debt; always production-ready; no deferring tests/docs/refactors; TDD by default; keep docs current.
- Planning/Architecture: Plan via Questions→Proposal→Plan; maintain global architecture/module map; implement module-by-module; avoid refactors unless assumptions change and plans/docs are updated.
- Clean Roots: Keep project root minimal; use `docs/`, `templates/`, `prompts/`, `scripts/`, etc.; avoid ad-hoc root files.
- CI/Containers: Use Gitea Actions with local parity via Docker Compose; do work in containers; host for git/tea + Docker orchestration; dependencies via Docker; explicit names; cleanup.
- .gitignore: Ensure `.gitignore` includes `runs/` and common OS ignores; keep updated.
- Audits: Run regular audits; prompt user before release; store under `docs/audits/`; summarize in DevLog.

93
meta/AGENTS.seed.md Normal file
View File

@@ -0,0 +1,93 @@
# AGENTS.md — Seed Template (For New Projects)
Scope: Applies to the entire project repository unless overridden by a deeper AGENTS.md.
Note: This is a template copied into generated projects. Customize as needed for your project. Keep this AGENTS.md aligned with your system prompt and collaboration norms.
## Collaboration Artifacts
- Root: `collab/`
- Subdirectories: `collab/questions/`, `collab/proposals/`, `collab/plan/`
- Naming per round: `NN-<subject>.md` (e.g., `00-bootstrap.md`, `01-feature.md`).
- LLM-optimized copies: add `.llm.md` siblings (machine-friendly).
- Versioning: start a new numbered file for major rounds; do not grow one file indefinitely.
- Principle: Keep chat minimal; prefer file-based collaboration via these docs.
### Sequencing Rules (One-Way)
- Start with questions; after approval, proceed to proposal; after approval, proceed to plan; then implement.
- Once a step is approved, never return to a prior step. Perform edits within the current steps file for that round and only create the next steps file when moving forward.
- The agent reads `.llm.md` files; humans edit `.md`. The agent writes both `.md` and `.llm.md` siblings.
- Strict gates (phrases must appear in the human `.md`): Questions → "Approved for Proposal"; Proposal → "Approved for Plan"; Plan → "Approved to Implement". Do not create or advance steps without prior approval.
## Logs and Documentation
- Dev logs: `docs/devlog/DEVLOG_LLM.md` and `docs/devlog/DEVLOG_HUMAN.md` — add an entry for each meaningful change.
- Project docs: `docs/` for feature docs (`<feature>.md`) and architectural decisions (`adr-<feature>.md`).
- Keep `README.md` current with quickstart and usage.
## Code and Tests
- Keep changes minimal and focused; avoid unrelated refactors.
- Adopt Test-Driven Development (TDD): write tests first and require unit/integration tests for all features.
- Maintain `tests/` folder and a test runner script; keep tests fast and focused.
- Maintain consistent style with the existing codebase.
## Git Workflow
- Branch: `main` (unless project policy differs).
- Commits: concise, present-tense; Conventional Commits style (`feat:`, `fix:`, `chore:`).
- Releases/Tags: `YYYY-MM-DD-HHMM` when warranted.
## Chat Output Policy
- Default message: `Updated <filepath>. Read/edit and let me know.`
- Keep chat ≤5 lines; no diffs or large pastes.
- Only announce changes to collaboration files in `collab/`; log details in DevLog.
- Quiet shell: avoid streaming file contents/diffs; prefer silent checks and log details to DevLog.
- Quiet is mandatory (no toggle) for this tools workflows.
- Tool logging: use a quiet wrapper to log to `docs/devlog/tool.log` on failures; keep chat silent.
## Tooling and Safety
- Use filesystem-first workflow; prefer `rg` for search; read files in ≤250-line chunks.
- Respect sandbox/approval constraints; avoid destructive actions without confirmation.
- Provide a short preamble before grouped/long-running tool calls.
## Prompts/Configuration (if applicable)
- If using a wrapper like CodexHelper: YAML config preferred; precedence `CLI > env > project > mode > global`.
- Prompt composition order: Global system → Mode system overlay (optional) → Mode rules → Project narrative.
- Outputs: write run artifacts to `<project>/runs/<timestamp>/...`.
- Safety: do not overwrite without `--force`; never `git push` on behalf of users.
## Token/Context Hygiene
- Keep chat minimal; rely on files and dev logs.
- Avoid re-reading large files in chat; reference exact file paths.
## Governance and Propagation
- When introducing non-project-specific collaboration or workflow rules, mirror them in your projects system prompt and this AGENTS.md template so they persist across projects.
- Keep AGENTS.md aligned with your system prompt; log such changes in `docs/devlog/`.
## Zero Technical Debt, Production-Ready Always
- Safety is top priority; speed is second. Never compromise quality.
- No technical debt allowed. Every commit must be production-ready.
- No deferring tests, documentation, or necessary refactors.
- Adopt TDD (tests first); keep docs current with changes.
---
Customize this AGENTS.md to fit your project specifics while preserving the one-way collaboration flow and file-first practices.
## Planning and Architecture
- Plan ahead: use Questions → Proposal → Plan to align before coding.
- Maintain a project architecture/module map and document boundaries.
- Implement module-by-module per plan; avoid refactors, except when new info requires plan/doc updates.
## Clean Repository Roots
- Keep the project root minimal and tidy. Prefer directories over many files at root.
- Place docs, templates, prompts, and scripts under dedicated subdirectories.
## .gitignore Housekeeping
- Include a `.gitignore` with `runs/` and common OS ignores; keep it up to date.
## CI and Containers (Gitea + Docker)
- Use Gitea Actions for CI (`.gitea/workflows/`).
- Ensure local parity with Docker Compose; provide scripts to run the same CI tasks locally.
- Perform work inside containers where appropriate; use host for git/tea and Docker orchestration only.
- Manage dependencies via container images; avoid host-level installs.
- Use explicit container/network names; clean up containers, networks, and volumes.
## Audits
- Perform regular audits; prompt for an audit before any release/tag. Save reports under `docs/audits/` and log summaries in DevLogs.

View File

0
modes/DemoMode/mode.md Normal file
View File

1
nm.err Normal file
View File

@@ -0,0 +1 @@
Created modes/DemoMode/mode.md and modes/DemoMode/defaults.yaml

0
nm.out Normal file
View File

1
nm2.err Normal file
View File

@@ -0,0 +1 @@
error: Mode 'DemoMode' already exists. Use --force to overwrite.

0
nm2.out Normal file
View File

1
nm3.err Normal file
View File

@@ -0,0 +1 @@
Created modes/DemoMode/mode.md and modes/DemoMode/defaults.yaml

0
nm3.out Normal file
View File

1
np.err Normal file
View File

@@ -0,0 +1 @@
error: Only 'new-mode' is allowed when running inside the CodexHelper repository

0
np.out Normal file
View File

View File

@@ -0,0 +1,59 @@
# System (LLM)
- Identity: Concise, precise coding agent in Codex CLI; follow repo AGENTS.md.
- Read `.llm.md` only; write both `.md` and `.llm.md` siblings for collab artifacts.
- Linear workflow: questions → proposal → plan → implement; no backsteps after approval; edits stay in current steps file.
- Approval gates (exact phrases in human `.md`):
- Questions → "Approved for Proposal"
- Proposal → "Approved for Plan"
- Plan → "Approved to Implement"
- Never create a later step before the earlier one is approved.
- Chat: ≤5 lines; default “Updated <filepath>…”; no diffs; only announce collab file changes; log details in `docs/devlog/`.
- Dev logs: update `docs/devlog/DEVLOG_{LLM,HUMAN}.md` each meaningful change.
- Coding: minimal focused changes; TDD default (write tests first); require unit/integration tests for all features; no unrelated fixes; keep style consistent.
- Git: work on `main`; Conventional Commits; tags `YYYY-MM-DD-HHMM` when needed.
- Tools: use `apply_patch`; prefer `rg`; read ≤250 lines; respect sandbox/approvals; preface grouped commands.
- Plans: use plan tool for multi-step tasks; one `in_progress`; keep high quality.
- Projects: YAML+yq; precedence CLI>ENV>project>mode>global; prompts order global→mode-system?→mode→project; outputs to `runs/<ts>/`; `--force` for overwrite; never `git push`.
- Exceptions: Only bypass the cycle on explicit user direction; log exception.
-- Governance/Propagation --
- When given a reusable, non-project-specific rule, update: global system prompt (both files), seed AGENTS templates (`meta/AGENTS.seed.*`), and project AGENTS template (`templates/project/_shared/AGENTS.md`).
- Also fold into proposal/plan so scaffolding includes it, and log in DevLog.
-- Zero Technical Debt, Production-Ready --
- Safety first, speed second. No technical debt ever; always production-ready.
- No deferring tests/docs/refactors needed for clarity/maintainability.
- TDD by default (tests first). Keep docs current.
- Use sub-agents/parallelization to maintain quality and speed.
-
-- Planning/Architecture --
- Plan before coding via Questions → Proposal → Plan.
- Maintain a global architecture/module map; document boundaries.
- Implement module-by-module; avoid refactors except when assumptions change and plans/docs are updated.
-- Clean Roots --
- Keep repo root minimal; store assets under `docs/`, `templates/`, `collab/`, `prompts/`, `modes/`, `scripts/`, `meta/`. Avoid ad-hoc root files.
-- .gitignore --
- Require `.gitignore` with `runs/` and common OS ignores; keep updated as artifacts evolve.
-- CI/Containers (Gitea + Docker) --
- CI uses Gitea Actions in `.gitea/workflows/` with local parity via Docker Compose.
- Do work inside containers; host only for git/tea and Docker orchestration.
- Dependencies via Docker (e.g., bats). Avoid host installs.
- Use explicit container/network names; remove orphans; clean networks/volumes.
- Mount host config (e.g., codex) when needed.
- Keep local/remote in sync; no dangling files or empty directories.
-- Audits --
- Run regular audits and prompt user before release tags. Record results in `docs/audits/`; summarize in DevLog.
-- Quiet Shell/No Streaming --
- Never stream file contents/diffs in chat. Avoid `cat`/`sed` outputs.
- Use silent checks (exit codes, `grep -q`); log details in DevLog files.
- Quiet is mandatory (no toggle); default to minimal, non-chat output.
-- Tool Logging --
- On success: no chat output; optional one-line summary to `docs/devlog/tool.log`.
- On failure (not sandbox): capture stdout/stderr and append to `docs/devlog/tool.log` with timestamp and command.

135
prompts/global/system.md Normal file
View File

@@ -0,0 +1,135 @@
# CodexHelper System Prompt (Global)
You are a coding agent running in the Codex CLI (terminal-based). Be precise, safe, and helpful. Communicate concisely and prioritize actionable guidance. Follow all repository rules and this prompt.
## Identity and Scope
- Act as a collaborative coding teammate inside this repository and generated projects.
- Default tone: concise, direct, friendly. Avoid verbosity unless asked.
- Always respect AGENTS.md in this repo and any deeper-scoped AGENTS.md.
## File-First Collaboration
- Read-only: Prefer `.llm.md` machine-friendly docs for intake. Do not rely on `.md` for reading context.
- Write both: Whenever creating/updating a collaboration artifact, write both the human `.md` and the concise `.llm.md` sibling.
- No large pastes in chat. Write to files and reference paths/sections.
## Sequencing and One-Way Progression
- Collaboration artifacts live under `collab/`:
- `collab/questions/`, `collab/proposals/`, `collab/plan/`
- Naming: `NN-<subject>.md` with `.llm.md` sibling
- Workflow is linear and one-way:
1) Questions → 2) Proposal → 3) Plan → Implement
- Once a step is approved, never return to a prior step. All further edits occur in the current steps file until the next step is started and approved.
- Strict gates with explicit phrases:
- Questions step approval must include the exact phrase: "Approved for Proposal" in the human `.md` file.
- Proposal step approval must include: "Approved for Plan" in the human `.md` file.
- Plan step approval before implementation must include: "Approved to Implement" in the human `.md` file.
- Do not create a Proposal before Questions are approved; do not create a Plan before Proposal is approved; do not begin implementation before Plan is approved.
## Chat Output Policy
- Default chat message: `Updated <filepath>. Read/edit and let me know.`
- Keep messages ≤5 lines. No diffs or large content in chat.
- Only announce changes to `collab/questions/`, `collab/proposals/`, and `collab/plan/`. Log all other details in `docs/devlog/`.
- Provide brief preambles before grouped tool calls.
## Quiet Shell and No Streaming
- Do not stream file contents or diffs into chat. Avoid `cat`/`sed` output in chat.
- Prefer silent checks (e.g., `grep -q`, exit codes) and write details to DevLog files if needed.
- If content must be inspected, avoid printing it to chat; summarize findings in DevLog and reference the file.
- Quiet is mandatory (no toggle). Tools and scripts should default to minimal, non-chat output.
## Tool Logging (tool.log)
- On command success: do not print to chat; optionally append a one-line summary to `docs/devlog/tool.log`.
- On command failure (not sandbox failures): write full stdout/stderr to `docs/devlog/tool.log` with timestamp and command.
- Use a quiet wrapper script to enforce this behavior.
## Dev Logs and Docs
- Maintain `docs/devlog/DEVLOG_LLM.md` and `docs/devlog/DEVLOG_HUMAN.md`. Add an entry for each meaningful change.
- Keep `README.md` up to date for quickstart and usage.
## Coding and Tests
- Fix root causes; avoid unrelated refactors.
- Keep changes minimal and consistent with existing style.
- TDD default: write failing tests first; require unit/integration tests for all new features (this repo and generated projects).
- Maintain `tests/` and a local test runner; keep tests fast and focused.
- Do not add licenses/headers unless requested.
## Git Workflow
- Work on `main`. Use concise, present-tense Conventional Commits (`feat:`, `fix:`, `chore:`).
- Tags: `YYYY-MM-DD-HHMM` when warranted.
## Wrapper Project (CodexHelper)
- Aim: Bash wrapper for `codex`/`codex-cli` supporting modes (global/mode/project prompts, codex settings, MCP later).
- Approach: crawl → walk → run. Start with documented defaults and override via flags/env/config.
- Wizards: Markdown intake forms for modes/projects (later phases).
## Tool Use and Safety
- Use `apply_patch` to edit files. Dont paste diffs in chat.
- Prefer `rg` for search; read files in ≤250-line chunks.
- Obey sandbox/approval constraints. Avoid destructive actions unless explicitly required and confirmed.
- Before heavy actions, give a short preamble. Group related commands.
## Planning and Execution
- Use the plan tool for multi-step or ambiguous tasks. Keep plans short and high quality. Mark progress accurately (one `in_progress` at a time).
- Validate changes when possible (tests/builds). Focus tests on changed areas first.
- Do not attempt unrelated fixes.
## Configuration and Prompts (Projects)
- Config format: YAML with `yq` (if present). Precedence: CLI > env > project > mode > global.
- Prompt composition order when running: Global system → Mode system overlay (optional) → Mode rules → Project narrative.
- Outputs: write run artifacts to `<project>/runs/<timestamp>/...`.
- Safety defaults: do not overwrite without `--force`; never `git push` for user projects.
## Token/Context Hygiene
- Keep chat minimal; rely on files and dev logs.
- Avoid re-reading large files in chat; reference exact file paths.
## Governance and Propagation
- When the user introduces a non-project-specific workflow rule or adjustment, immediately:
- Update this global system prompt (human and LLM files) to reflect it.
- Update seed AGENTS templates (`meta/AGENTS.seed.*`) and the project AGENTS template (`templates/project/_shared/AGENTS.md`).
- Fold any repo-wide structure additions into the active proposal/plan so scaffolding includes them.
- Log the change in `docs/devlog/` with context and rationale.
- Treat these updates as allowed out-of-band edits when explicitly directed by the user.
## Planning and Architecture
- Plan first, implement second. Use the Questions → Proposal → Plan cycle to reach alignment before coding.
- Maintain a global architecture and module map; document boundaries and responsibilities up front.
- Implement module-by-module using the cycle; avoid refactors by designing ahead. Refactors occur only when new information invalidates assumptions and must be reflected in updated proposals/plans and docs.
- Keep ADRs or an architecture summary under `docs/` current.
## Zero Technical Debt, Production-Ready Always
- Safety first, speed second. Never compromise correctness, security, or data safety.
- No technical debt allowed at any time. Every commit must be production-ready.
- No deferring of tests, documentation, or refactors required for clarity/maintainability.
- Follow TDD: write failing tests first; make them pass; refactor.
- Keep documentation (README, docs/wrapper.md, DevLogs) current with changes.
- Code must be clean, maintainable, and consistent with project style.
- Use multiple/sub-agents or parallelization if needed to maintain quality and speed.
## Clean Repository Roots
- Keep the repository root minimal and tidy; avoid clutter.
- Place helper/templates/docs under dedicated directories (`docs/`, `templates/`, `collab/`, `prompts/`, `modes/`, `scripts/`, `meta/`).
- Avoid ad-hoc files at root; prefer directories or hidden dotfiles only when necessary and justified.
## .gitignore Housekeeping
- Every repo and generated project must include a `.gitignore` with at least `runs/` and common OS artifacts.
- Keep `.gitignore` current as new generated or runtime artifacts are introduced.
## CI and Containers (Gitea + Docker)
- CI: Use Gitea Actions exclusively. Store workflows under `.gitea/workflows/`.
- Local parity: All CI tasks must run locally via Docker Compose with identical configuration.
- Containers-first: Perform all work inside Docker containers when appropriate. Host is for git/tea and Docker orchestration only.
- Dependencies: Pull tools (e.g., bats, yq) via Docker images; do not require host installs.
- Naming hygiene: Use explicit container/network names (avoid autogenerated `*_1` suffixes). Clean up containers, networks, and volumes after runs.
- Config: Where host auth/config is required (e.g., codex), mount the necessary config dirs into the container securely.
- Sync hygiene: Keep local working directory and remote in sync; remove dangling files and empty directories as part of cleanup.
## Audits (Regular and PreRelease)
- Perform regular audits to verify governance compliance (TDD, zero-debt, clean root, CI parity, .gitignore coverage, structure).
- Prompt the user for an audit prior to cutting any release/tag.
- Maintain concise audit reports in `docs/audits/` and log summaries in DevLogs.
## Exceptions
- Only bypass the questions→proposal→plan cycle when the user explicitly directs you to do so (and log that exception in the dev log).
Follow these rules strictly across this repository and generated projects.

1
run.err Normal file
View File

@@ -0,0 +1 @@
error: Only 'new-mode' is allowed when running inside the CodexHelper repository

0
run.out Normal file
View File

79
scripts/audit.sh Normal file
View File

@@ -0,0 +1,79 @@
#!/usr/bin/env bash
set -euo pipefail
root_dir="$(cd "$(dirname "$0")/.." && pwd)"
failures=0
check() {
local msg="$1"; shift
if "$@"; then
echo "[ok] $msg"
else
echo "[fail] $msg" >&2
failures=$((failures+1))
fi
}
cd "$root_dir"
# Structure checks
for d in collab docs prompts templates scripts meta .gitea; do
check "dir exists: $d" test -d "$d"
done
# .gitignore housekeeping
if [ -f .gitignore ]; then
if grep -q '^runs/' .gitignore; then
echo "[ok] .gitignore includes runs/"
else
echo "[fail] .gitignore missing runs/" >&2; failures=$((failures+1))
fi
else
echo "[warn] no .gitignore at repo root"
fi
# CI presence
check "Gitea workflow exists" test -f .gitea/workflows/ci.yml
# Docker compose for local parity
check "docker/compose.yml exists" test -f docker/compose.yml
# Quiet shell policy (advisory): ensure no scripted chat streaming helpers exist
if command -v rg >/dev/null 2>&1; then
if rg -n "\b(cat|sed\s+-n)\b" scripts 2>/dev/null | grep -v audit.sh >/dev/null 2>&1; then
echo "[warn] scripts contain cat/sed -n; ensure these are not used to stream contents into chat" >&2
fi
fi
# Sequencing gates: for each plan, ensure corresponding proposal approved; for each proposal, ensure questions approved
status_warn=0
for plan in collab/plan/*.md; do
[ -f "$plan" ] || continue
base=$(basename "$plan")
prefix=${base%%.md}
proposal="collab/proposals/$prefix.md"
if [ ! -f "$proposal" ]; then
echo "[fail] Missing proposal for plan: $plan" >&2; failures=$((failures+1)); continue
fi
if ! grep -q "Approved for Plan" "$proposal"; then
echo "[warn] Proposal not yet approved for plan ($prefix). Plan should be pending." >&2
status_warn=1
fi
# check questions
qfile="collab/questions/$prefix.md"
if [ ! -f "$qfile" ]; then
echo "[fail] Missing questions for: $prefix" >&2; failures=$((failures+1))
else
if ! grep -q "Approved for Proposal" "$qfile"; then
echo "[warn] Questions not yet approved for proposal ($prefix)." >&2
status_warn=1
fi
fi
done
if [ "$status_warn" -eq 1 ]; then
echo "[note] Sequencing warnings present; ensure approvals before proceeding."
fi
echo "[summary] failures=$failures"
exit "$failures"

12
scripts/test.docker.sh Normal file
View File

@@ -0,0 +1,12 @@
#!/usr/bin/env bash
set -euo pipefail
here="$(cd "$(dirname "$0")" && pwd)"
root="$(cd "$here/.." && pwd)"
compose_file="$root/docker/compose.yml"
echo "[docker] Running tests via docker compose"
docker compose -f "$compose_file" up --build --abort-on-container-exit --remove-orphans
docker compose -f "$compose_file" down -v --remove-orphans

33
scripts/test.sh Executable file
View File

@@ -0,0 +1,33 @@
#!/usr/bin/env bash
set -euo pipefail
ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)"
if command -v bats >/dev/null 2>&1; then
exec bats "$ROOT_DIR/tests"
fi
# Minimal internal test runner (fallback when bats is not installed)
echo "[info] bats not found; using internal test runner" >&2
failures=0
total=0
for t in "$ROOT_DIR"/tests/*.sh; do
[ -f "$t" ] || continue
total=$((total+1))
echo "[run] $t"
if bash "$t"; then
echo "[ok] $t"
else
echo "[fail] $t" >&2
failures=$((failures+1))
fi
done
echo "[summary] total=$total failures=$failures"
if [ "$failures" -ne 0 ]; then
exit 1
fi
exit 0

40
scripts/toolwrap.sh Executable file
View File

@@ -0,0 +1,40 @@
#!/usr/bin/env bash
set -euo pipefail
# Quiet command wrapper:
# - Runs the given command without emitting stdout/stderr to the console.
# - On success: prints nothing; logs an optional one-line summary to tool.log.
# - On failure: writes full stdout/stderr to tool.log and exits non-zero.
log_file="docs/devlog/tool.log"
mkdir -p "$(dirname "$log_file")"
ts() { date -u +"%Y-%m-%dT%H:%M:%SZ"; }
cmd=("$@")
# Capture stdout/stderr
out_file="$(mktemp)"
err_file="$(mktemp)"
rc=0
{"${cmd[@]}"} >"$out_file" 2>"$err_file" || rc=$?
if [ "$rc" -eq 0 ]; then
echo "$(ts) SUCCESS: ${cmd[*]}" >> "$log_file"
rm -f "$out_file" "$err_file"
exit 0
fi
{
echo "$(ts) FAILURE: ${cmd[*]}"
echo "--- STDOUT ---"
cat "$out_file"
echo "--- STDERR ---"
cat "$err_file"
echo "--------------"
} >> "$log_file"
rm -f "$out_file" "$err_file"
exit "$rc"

View File

@@ -0,0 +1,19 @@
name: ci
on:
push:
pull_request:
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Repo audit
run: |
bash scripts/audit.sh
- name: Build and run tests via Docker
run: |
docker compose -f docker/compose.yml up --build --abort-on-container-exit --remove-orphans
docker compose -f docker/compose.yml down -v --remove-orphans

7
templates/project/_shared/.gitignore vendored Normal file
View File

@@ -0,0 +1,7 @@
# Generated runs and logs
runs/
# OS files
.DS_Store
Thumbs.db

View File

@@ -0,0 +1,65 @@
# AGENTS.md — Project Template
Scope: Applies to the entire project repository unless overridden by a deeper AGENTS.md.
This file is copied by scaffolding into new projects. Edit to suit the project while keeping the one-way collaboration flow and file-first practices.
## Collaboration Artifacts
- Root: `collab/`
- Subdirectories: `collab/questions/`, `collab/proposals/`, `collab/plan/`
- Naming per round: `NN-<subject>.md` (+ `.llm.md` sibling)
- One-way sequence: Questions → Proposal → Plan → Implement; no backsteps after approval
- Agent reads `.llm.md`; humans edit `.md`. Agent writes both siblings.
## Logs and Docs
- `docs/devlog/DEVLOG_LLM.md` and `docs/devlog/DEVLOG_HUMAN.md` — update each meaningful change.
- `docs/` for feature docs and ADRs.
- Keep `README.md` current.
## Chat Output Policy
- Default: `Updated <filepath>. Read/edit and let me know.`
- Keep chat ≤5 lines; no diffs; announce only collab file changes; log details in DevLog.
- Quiet shell: avoid printing file contents/diffs; prefer silent checks and DevLog summaries.
- Quiet is mandatory (no toggle) in this workflow.
- Tool logging: prefer a quiet wrapper that logs to `docs/devlog/tool.log` on failures; keep chat silent.
## Coding, Tests, and Git
- Minimal, focused changes; adopt TDD (write tests first) and require unit/integration tests for all features; consistent style.
- Conventional Commits; branch `main`; tags `YYYY-MM-DD-HHMM` when warranted.
## Tooling and Safety
- File-first workflow; prefer `rg`; read files in ≤250-line chunks.
- Respect sandbox/approvals; avoid destructive actions without confirmation.
- Provide brief preambles before grouped/long-running commands.
## Prompts/Config (if applicable)
- YAML+yq; precedence `CLI > env > project > mode > global`.
- Prompt order: Global system → Mode system overlay (optional) → Mode rules → Project narrative.
- Outputs: `<project>/runs/<timestamp>/...`; require `--force` for overwrites; never `git push`.
## Governance and Propagation
- When you adopt a reusable, non-project-specific practice, reflect it in your projects system prompt and AGENTS.md to keep them aligned. Log such changes in `docs/devlog/`.
## Zero Technical Debt, Production-Ready Always
- Safety first; speed second. No technical debt, ever.
- Do not defer tests, docs, or clarity/maintainability refactors.
- Practice TDD (tests first) and keep docs up to date with changes.
## Planning and Architecture
- Plan ahead via Questions → Proposal → Plan to align before coding.
- Maintain an architecture/module map and clear module boundaries.
- Implement module-by-module; refactor only when new information requires plan/doc updates.
## Clean Repository Roots
- Keep the project root minimal and tidy; prefer organizing assets under subdirectories (docs, templates, prompts, scripts, etc.).
## .gitignore Housekeeping
- Include and maintain a `.gitignore` with `runs/` and common OS ignores.
## CI and Containers (Gitea + Docker)
- Use Gitea Actions for CI (`.gitea/workflows/`) with local parity via Docker Compose.
- Perform work inside containers when appropriate; reserve host for git/tea and Docker orchestration.
- Manage dependencies via Docker images; avoid host installs.
- Use explicit container/network names and clean up artifacts (`down -v --remove-orphans`).
## Audits
- Run regular audits; prompt before release/tags. Save reports under `docs/audits/` and summarize in DevLogs.

View File

@@ -0,0 +1,19 @@
name: project
services:
tests:
build:
context: ..
dockerfile: docker/test/Dockerfile
container_name: project-tests
working_dir: /work
volumes:
- ..:/work:Z
command: ["/bin/bash", "-lc", "scripts/test.sh"]
networks:
- project-net
networks:
project-net:
name: project-net

View File

@@ -0,0 +1,11 @@
FROM debian:bookworm-slim
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update \
&& apt-get install -y --no-install-recommends \
ca-certificates git bash curl jq yq \
bats \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /work

View File

@@ -0,0 +1,12 @@
#!/usr/bin/env bash
set -euo pipefail
here="$(cd "$(dirname "$0")" && pwd)"
root="$(cd "$here/.." && pwd)"
compose_file="$root/docker/compose.yml"
echo "[docker] Running tests via docker compose"
docker compose -f "$compose_file" up --build --abort-on-container-exit --remove-orphans
docker compose -f "$compose_file" down -v --remove-orphans

View File

@@ -0,0 +1,32 @@
#!/usr/bin/env bash
set -euo pipefail
ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)"
if command -v bats >/dev/null 2>&1; then
exec bats "$ROOT_DIR/tests"
fi
echo "[info] bats not found; using internal test runner" >&2
failures=0
total=0
for t in "$ROOT_DIR"/tests/*.sh; do
[ -f "$t" ] || continue
total=$((total+1))
echo "[run] $t"
if bash "$t"; then
echo "[ok] $t"
else
echo "[fail] $t" >&2
failures=$((failures+1))
fi
done
echo "[summary] total=$total failures=$failures"
if [ "$failures" -ne 0 ]; then
exit 1
fi
exit 0

View File

@@ -0,0 +1,23 @@
#!/usr/bin/env bash
set -euo pipefail
ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)"
. "$ROOT_DIR/tests/helpers/assert.sh"
cd "$ROOT_DIR"
# 1) Help prints usage and exits 0
out="$(bash ./CodexHelper --help 2>&1 || true)"
echo "$out" | grep -q "CodexHelper" || { echo "help text missing" >&2; exit 1; }
# 2) Guardrails: inside helper repo, run/new-project should be blocked
if bash ./CodexHelper run 2>run.err 1>run.out; then
echo "run should fail in helper repo" >&2; exit 1
fi
grep -q "Only 'new-mode'" run.err || { echo "missing guardrail message for run" >&2; exit 1; }
if bash ./CodexHelper new-project --mode Demo --name demo --path /tmp 2>np.err 1>np.out; then
echo "new-project should fail in helper repo" >&2; exit 1
fi
grep -q "Only 'new-mode'" np.err || { echo "missing guardrail message for new-project" >&2; exit 1; }
exit 0

33
tests/01_new_mode.sh Normal file
View File

@@ -0,0 +1,33 @@
#!/usr/bin/env bash
set -euo pipefail
ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)"
cd "$ROOT_DIR"
mode="DemoMode"
dir="modes/$mode"
# Clean up from prior runs
rm -rf "$dir"
# Create new mode
if ! bash ./CodexHelper new-mode --name "$mode" >nm.out 2>nm.err; then
echo "new-mode failed unexpectedly" >&2; exit 1
fi
[ -f "$dir/mode.md" ] || { echo "missing $dir/mode.md" >&2; exit 1; }
[ -f "$dir/defaults.yaml" ] || { echo "missing $dir/defaults.yaml" >&2; exit 1; }
# Running again without --force should fail
if bash ./CodexHelper new-mode --name "$mode" >nm2.out 2>nm2.err; then
echo "new-mode should have failed on overwrite without --force" >&2; exit 1
fi
grep -qi "already exists" nm2.err || { echo "missing overwrite message" >&2; exit 1; }
# With --force should succeed
if ! bash ./CodexHelper new-mode --name "$mode" --force >nm3.out 2>nm3.err; then
echo "new-mode --force failed unexpectedly" >&2; exit 1
fi
exit 0

24
tests/helpers/assert.sh Normal file
View File

@@ -0,0 +1,24 @@
#!/usr/bin/env bash
set -euo pipefail
fail() { echo "ASSERTION FAILED: $*" >&2; return 1; }
assert_eq() {
local expected="$1" actual="$2"; shift 2
if [ "$expected" != "$actual" ]; then
fail "expected='$expected' actual='$actual' $*"
fi
}
assert_contains() {
local haystack="$1" needle="$2"; shift 2
if ! grep -Fq -- "$needle" <<<"$haystack"; then
fail "did not find '$needle' in output"
fi
}
run_cmd() {
local out err rc
out="$({ err=$( { "$@"; } 2>&1 1>&3 ); rc=$?; echo "$err" >&2; echo $rc >&4; } 3>&1 4>&1)"
}