One project. One clear set of rules.

Problem and interpretation: Without these links, an agent can treat an old description or its own assumption as the current decision. Code shows the current state, but it is not automatic permission to change the goal.

When Codex uses it: At the start of a task, before choosing files to change or proposing a solution.

What the reader adapts: Add the goal's name and real links to requirements, decisions, and the plan. In Adrian Lab, these include docs/plan.md and the material's canonical article.md.

Result: Codex starts from the right goal and knows where to check the current decisions.

Technical acceptance covers secrets, security, data, permissions, and compliance with project rules. Completion means the agreed result, required checks, independent review, closed fixes and decisions, current knowledge, disclosed limits, and evidence for the assessed version.

Problem and interpretation: A successful build is not technical acceptance. This section separates agent execution, checks, and the decision of the responsible person. One approval for a concrete package lets ordinary work finish within its boundary; it is not approval for external actions.

When Codex uses it: When preparing a change for review and reporting its status.

What the reader adapts: List only commands someone has verified; when none exist, say so plainly. Adrian Lab root AGENTS.md lists, among others, npm run build, npm test, and content tests.

Result: the person accepting the work can see what to run, what was checked, and what remains.

Problem and interpretation: “Help with the project” does not authorize changing its goal or standards, publishing, or editing the same files in parallel. A shared plan keeps the state outside conversation history. Judge an access boundary by its effect, not by the filename or subsystem.

When Codex uses it: Before changing scope, handing work to someone else, or taking an action that needs a decision.

What the reader adapts: Describe real scope and roles. In a solo project, you can name yourself as the decision-maker, but still name actions that require your explicit approval.

Result: Codex knows which actions it may take and when it must stop for a decision.

A repeatable specialist process belongs in a Skill, rather than an ever-longer root AGENTS.md.

Problem and interpretation: One huge file mixes rules for different people and files. A Skill file existing does not prove that the tool in use discovers it.

When Codex uses it: When starting work in a specific directory or when a process repeats often enough to document once.

What the reader adapts: Add only instructions and Skills that really exist. Adrian Lab has content/AGENTS.md for materials, and root AGENTS.md says when to read it. Do not create Skill synchronization without a real need. If synchronization exists, it may remove only its own managed files, must block paths outside the allowed directory, preserve independently installed Skills, and stop on a conflict outside its manifest. Verify discovery in a fresh session of every tool after a change.

Result: rules stay close to the work they govern, and the tool has confirmed instructions instead of incidental files.

The agent works within existing access boundaries and first identifies the technology stack.

Problem and interpretation: Asking for a “quick workaround” to a block or installing a new tool can breach access rules and create maintenance cost. Repairing validation of existing access does not expand that access. No technology decision is not a positive decision.

When Codex uses it: Before asking for permissions, connecting an external service, adding a dependency, or reading configuration.

What the reader adapts: Record applicable standards and account boundaries safely, without secret values. Adrian Lab also prohibits recording tokens, client data, and private materials in the repository.

Result: the agent works within agreed boundaries without exposing secrets or bypassing access protection.

The section also covers component libraries, design systems, brand book, reference screens, phone, accessibility, and shared interface states.

Problem and interpretation: An agent should not choose a framework, UI library, or authentication system merely because it knows it from another project. The same applies to a design system, reference screens, phone, and accessibility.

When Codex uses it: Before implementation, dependency installation, or building a new screen.

What the reader adapts: Complete only approved technologies, versions, and decision sources. Adrian Lab root AGENTS.md names React 19, Vite 6, and the existing visual language of the home page; it does not invent a backend. When the standard is undecided, the agent presents cost, limits, and at most one technology alternative; for a UI library, at most three compatible proposals and one direction. Installation waits for a decision.

Result: a new feature follows the agreed stack and interface rather than introducing arbitrary tools.

If it gives progress, it calculates it from one current plan with source, numerator, and denominator. It does not equate task count with time or readiness, count partial tasks as accepted, or invent weights or percentages.

Problem and interpretation: “Ready” can easily hide a missing test or pending acceptance. A progress percentage has meaning only when it follows the current plan and gives a numerator and denominator.

When Codex uses it: At the end of a task and after a meaningful stage is complete.

What the reader adapts: Name one existing status location. In Adrian Lab, that is docs/plan.md or content/QUEUE.md, depending on the area. Do not create a journal only to report progress. When the plan is incomplete, state the known status without a percentage. When the whole scope is complete, name acceptance or no further work instead of adding an artificial next step.

Result: the report separates execution from acceptance and names who owns the next specific action.

Show one view or flow, collect feedback, make a small correction with a risk-appropriate check, then show the same view. After the whole series of changes, ask separately for acceptance of the named stage. A break without acceptance pauses the session, and state and open feedback go into the existing plan.

Problem and interpretation: The end of comments, silence, or “OK” after one small correction does not automatically accept the entire demo. Demo acceptance also does not replace technical acceptance, approval to merge, or publication.

When Codex uses it: After a meaningful interface stage; for a stage without an interface, it shows the artifact and verification evidence. After acceptance, it brings the change to architecture, testing, security, and integration requirements, removes provisional work, and performs required checks. A change to accepted behavior returns to demo.

What the reader adapts: Name the project, stage, and views that can actually be shown. Use a safe preview and fictional data while preserving secret protection and account boundaries. Demo acceptance does not replace technical acceptance or approval to merge or release. When blocked, state why and record “demo pending” in the existing plan; do not claim a demonstration that did not happen.

Result: the user reviews a visible stage while the team keeps a clear boundary between the demo, technical acceptance, and release.

What it says: In Adrian Lab, the plan explicitly declares itself the only active plan, and every stage has a named status, owner, result, and evidence.

Problem and interpretation: Status kept only in conversation history becomes stale quickly. Several parallel plans can point to conflicting next steps. One plan gives the next session a verifiable starting point.

When Codex uses it: At the start of a task, at a meaningful stage boundary, before handoff, and when reporting status and the next step. docs/plan.md existing by itself does not cause it to load automatically.

What the reader adapts: Choose one plan path in your project and name it in AGENTS.md. Do not copy Adrian Lab's historical stages. Use your own stages, owners, evidence, and gates.

Result: project state stays in one place that the next session can verify without reconstructing conversation history.

What it says: The real L-002 separates observation, cause, evidence, application, and status. It records the relationship: learning in learnings.md → durable direction in root AGENTS.md → detailed rules in content/AGENTS.md.

Problem and interpretation: Without evidence, a random one-off situation can become an overly broad rule. A rule that exists only in the learning register may not be used because ordinary Markdown is not automatically an instruction.

When Codex uses it: When a repeatable error or observation has evidence and changes future work. Once confirmed, it moves the actual rule to one governing place and leaves evidence and a link in the register.

What the reader adapts: If your project does not need a register, remove the file and its link. Do not copy the active status from Adrian Lab: verify it yourself in a fresh task first.

Result: a verified learning becomes a durable rule rather than an unverified note.