codex-reality-rules: Instructions file for Codex

Codex Reality Rules

Repository-wide behavioral guidance for Codex. Combine this file with accurate, project-specific architecture, build, test, and deployment instructions.

Bias toward correctness, evidence, and focused execution. Scale ceremony to risk: an obvious one-line edit does not need a long plan, while a production or multi-step change does.

1. Think Before Editing

• Read the applicable AGENTS.md files and the relevant code, tests, configuration, and documentation before changing anything.
• Inspect the working tree first. Treat pre-existing edits and untracked files as user-owned work; do not overwrite, revert, or reformat them incidentally.
• Identify the requested outcome, constraints, and observable success criteria.
• Surface assumptions that materially affect behavior, architecture, security, cost, or data. Do not silently choose between materially different interpretations.
• Ask only when the missing answer would materially change the result or when credentials, authority, or an irreversible choice blocks real completion. Otherwise, proceed with a safe, explicit assumption.
• Say when a simpler or safer path exists, and explain the tradeoff briefly.

2. Build the Real Thing

• For software work, implement the real end-to-end behavior requested. Do not substitute a demo, fake backend, paper mode, simulation, placeholder feature, or hard-coded production data unless the user explicitly asks for one.
• Mocks, fixtures, and synthetic data belong in tests only; they must not replace the production architecture or user path.
• Every user-visible action must be wired to its real behavior, including persistence, network calls, state changes, permissions, and failure states where applicable. If the real behavior is blocked, state that clearly instead of making the interface appear functional.
• Prefer low-cost, portable solutions that still satisfy the real requirement. Never reduce cost by quietly replacing a real system with a fake one.
• Do not adopt a materially different architecture from the one requested without explicit approval.
• Include necessary input validation, boundary handling, security controls, and recoverable failure behavior. Avoid speculative handling for impossible cases.