Codex AutoLoop Repository Instructions

Purpose

This repository uses specification-driven development and bounded autonomous loops. When a user asks to create a product, feature, or substantial behavioral change, use the autoloop skill. A direct $autoloop invocation authorizes the in-repository lifecycle described by that skill, including scoped GitHub Issues, branches, commits, pull requests, review requests, and auto-merge arming for the current repository when credentials and repository protections are already configured.

Do not use AutoLoop for a narrow explanation, read-only review, or a trivial edit unless the user asks for it.

When a user says 初期設定して, セットアップして, or otherwise asks to initialize a copied template, use the autoloop-setup skill. This repository uses ChatGPT subscription sign-in and native Codex GitHub reviews; never request OPENAI_API_KEY for AutoLoop setup.

Lifecycle invariants

• Do not implement product behavior before the active specification is validated and locked.
• Keep specification and implementation in separate pull requests when GitHub is configured.
• Treat the locked specification and acceptance criteria as the source of truth.
• Do not change a locked specification from an implementation pull request.
• Every behavioral task and test must reference at least one acceptance-criteria ID.
• Run repository validation and every configured gate before opening or updating an implementation pull request.
• Use bounded loops. On repeated failure or exhausted limits, transition to AUTOMATION_BLOCKED and do not merge.
• Never force-push.

No human approval gates

The AutoLoop lifecycle does not pause for human approval after intake. Missing product information may be obtained through a short interview. When the user declines to choose, record a conservative, reversible assumption in the specification.

After intake, replace subjective approval with evidence gates:

• specification structure and consistency;
• acceptance-criteria traceability;
• deterministic CI;
• specification-conformance review;
• independent Codex review;
• security checks;
• protected control-plane integrity.

Failure policy

Fail closed. Do not merge when any required evidence is absent, stale, ambiguous, skipped unexpectedly, or produced for an older commit.

Transition to AUTOMATION_BLOCKED when any of these occurs:

• a loop reaches its configured maximum;
• the same failure repeats beyond its configured maximum;
• credentials or required GitHub protection are unavailable;
• a required test cannot run;
• a change requires weakening a quality or security policy;
• the implementation cannot satisfy the locked specification without changing scope.

Prohibited shortcuts

• Do not delete, skip, weaken, or make assertion-free tests to obtain a passing result.
• Do not lower coverage, lint, type, security, or build thresholds.
• Do not suppress failures or convert failures to warnings.
• Do not alter .github/workflows/**, .github/codex/**, .agents/skills/**, AutoLoop policy/schema/template files, controller/setup scripts, controller self-tests, or AGENTS.md from a managed feature pull request. The only permitted control change in a managed specification pull request is project identity and quality-gate commands in .autoloop/config.json; all autonomy, limit, GitHub, and protected-path settings must remain unchanged.
• Do not put secrets in files, logs, prompts, issues, pull requests, commits, or artifacts.
• Do not reinterpret or weaken acceptance criteria to match incomplete code.

Code Review Rules

Specification conformance

• Flag behavior that contradicts the locked specification.
• Flag missing handling for specified failure, boundary, and empty states.
• Flag acceptance criteria without meaningful verification evidence.
• Flag implementation scope not justified by the active specification.

Test integrity

• Flag removed, skipped, weakened, tautological, or assertion-free tests.
• Flag tests that validate implementation details while missing required behavior.
• Flag reduced coverage or quality thresholds.

Security and data integrity

• Flag secrets, unsafe authorization, injection risks, and sensitive-data exposure.
• Flag destructive data changes without reversible migration and recovery handling.
• Flag new third-party access or privilege expansion not required by the specification.

Automation integrity

• Flag attempts to weaken CI, review gates, branch protections, loop limits, or protected paths.
• Flag generated evidence that does not correspond to the latest commit.

Required local commands

Before reporting success, run:

python scripts/autoloop/autoloop.py validate
python scripts/autoloop/autoloop.py verify
python -m unittest discover -s tests -v

On systems where the Python command is python3, use python3 instead.