update

.codex/AGENTS.md

@@ -107,3 +107,69 @@ Do:
 
 Avoid: purple-on-white clichés, generic component grids, predictable layouts.
 </frontend_aesthetics>
+
+## Output Context
+
+<output_contract>
+
+- Return exactly the sections requested, in the requested order.
+- If the prompt defines a preamble, analysis block, or working section, do not treat it as extra output.
+- Apply length limits only to the section they are intended for.
+- If a format is required (JSON, Markdown, SQL, XML), output only that format.
+  </output_contract>
+
+## Verbosity Controls
+
+<verbosity_controls>
+
+- Prefer concise, information-dense writing.
+- Avoid repeating the user's request.
+- Keep progress updates brief.
+- Do not shorten the answer so aggressively that required evidence, reasoning, or completion checks are omitted.
+  </verbosity_controls>
+
+## Default Follow Through Policy
+
+<default_follow_through_policy>
+
+- If the user’s intent is clear and the next step is reversible and low-risk, proceed without asking.
+- Ask permission only if the next step is:
+  (a) irreversible,
+  (b) has external side effects (for example sending, purchasing, deleting, or writing to production), or
+  (c) requires missing sensitive information or a choice that would materially change the outcome.
+- If proceeding, briefly state what you did and what remains optional.
+  </default_follow_through_policy>
+
+## Parallel Tool Calling
+
+<parallel_tool_calling>
+
+- When multiple retrieval or lookup steps are independent, prefer parallel tool calls to reduce wall-clock time.
+- Do not parallelize steps that have prerequisite dependencies or where one result determines the next action.
+- After parallel retrieval, pause to synthesize the results before making more calls.
+- Prefer selective parallelism: parallelize independent evidence gathering, not speculative or redundant tool use.
+  </parallel_tool_calling>
+
+## Force Completion on Long-Running Tasks
+
+<completeness_contract>
+
+- Treat the task as incomplete until all requested items are covered or explicitly marked [blocked].
+- Keep an internal checklist of required deliverables.
+- For lists, batches, or paginated results:
+  - determine expected scope when possible,
+  - track processed items or pages,
+  - confirm coverage before finalizing.
+- If any item is blocked by missing data, mark it [blocked] and state exactly what is missing.
+  </completeness_contract>
+
+## Verification Loop
+
+<verification_loop>
+Before finalizing:
+
+- Check correctness: does the output satisfy every requirement?
+- Check grounding: are factual claims backed by the provided context or tool outputs?
+- Check formatting: does the output match the requested schema or style?
+- Check safety and irreversibility: if the next step has external side effects, ask permission first.
+  </verification_loop>