Apply codex-kit v1.1.3

Author: iamdevlinph

.codex-kit-state.json

@@ -1,9 +1,9 @@
 {
   "version": 1,
   "template": {
-    "availableHash": "0510d5c80f92f0815a5aa62ee934a1dc00db21b261e41233fa3fdfe3f1da1c3b",
-    "availableVersion": "1.1.2",
-    "appliedHash": "0510d5c80f92f0815a5aa62ee934a1dc00db21b261e41233fa3fdfe3f1da1c3b",
-    "appliedAt": "2026-08-10T16:56:02.096Z"
+    "availableHash": "e4bb65fb695d015deea1af3d1171dfe2a3d00a71401230c5ff6da60bf2e56bc4",
+    "availableVersion": "1.1.3",
+    "appliedHash": "e4bb65fb695d015deea1af3d1171dfe2a3d00a71401230c5ff6da60bf2e56bc4",
+    "appliedAt": "2026-08-12T03:41:20.896Z"
   }
 }

AGENTS.md

@@ -23,6 +23,10 @@ Biome is authoritative: use tabs, double quotes, and organized imports. Follow n
 
 Use intent-revealing domain names. A reader should understand what a variable contains or what a helper guarantees at the call site without opening its implementation. Avoid vague transformation names such as `normalized`, `processed`, `result`, or `data` when a value- or behavior-specific name is available.
 
+Replace numeric literals that encode domain rules, limits, durations, units, or protocol values with descriptively named constants. Obvious structural values, such as basic indexes or empty-state values, may remain inline.
+
+Prefer clear structure, and simplify or extract complex logic before relying on comments. Use comments to explain non-obvious purpose, constraints, invariants, tradeoffs, or workarounds, not to narrate statements.
+
 Keep naming conventions consistent within each code-owned object, schema, type, and module. Use `snake_case` for app-owned domain/data record fields and serialized form/store records; use `camelCase` for functions, variables, React/framework props and APIs, state, other code-owned object properties, and ordinary local `const` bindings; use `PascalCase` for types/components; and use `UPPER_SNAKE_CASE` for module-level constants, enum members, and lookup keys. Preserve externally defined names at the boundary, then map them once to the project's internal convention.
 
 Name custom hooks as `useThing`, higher-order components as `withThing`, local event-handler functions as `handleThing`, and code-owned callback props with an `onThing` prefix. Prefix boolean props, state, and variables with `is`, `has`, or `should` when the prefix accurately describes their meaning.

TEMPLATE_AGENTS.md

@@ -92,6 +92,10 @@ conditional procedures into validated project skills.
 - Reuse existing constants, schemas, enums, shared types, and components before
   creating duplicates. Add reusable domain values at their existing source of
   truth instead of scattering magic strings.
+- Replace numeric literals that encode domain rules, limits, durations, units,
+  or protocol values with descriptively named constants. Universally obvious
+  structural values, such as basic indexes or empty-state values, may remain
+  inline.
 - Promote repeated closed-set domain values used in production control flow to
   feature-owned immutable runtime constants. Where the language supports it,
   derive static types from that runtime source; keep incidental presentation,
@@ -184,7 +188,9 @@ conditional procedures into validated project skills.
   contains or what a helper guarantees at the call site without opening its
   implementation. Avoid vague transformation names such as `normalized`,
   `processed`, `result`, or `data` when a value- or behavior-specific name is
-  available.
+  available. Prefer clear structure, and simplify or extract complex logic before
+  relying on comments. Use comments to explain non-obvious purpose, constraints,
+  invariants, tradeoffs, or workarounds, not to narrate statements.
 - Keep naming conventions consistent within each code-owned object, schema,
   type, and module. Do not mix identifier casing styles in the same
   representation unless required by an external contract or framework.