@iamdevlinph/codex-kit 1.1.2 → 1.1.4

package/README.md

@@ -43,6 +43,23 @@ The root orchestrator plans, routes, integrates, and validates. It handles clear
 small changes directly and delegates broader discovery, implementation, or review
 according to the installed `SUBAGENT_ROUTING.md` policy.
 
+## Project guidance included
+
+The canonical [project guidance template](TEMPLATE_AGENTS.md) provides reusable
+defaults for coding agents across these themes:
+
+- instruction scope, local adaptation, and specialized project skills;
+- minimal changes that follow the repository's existing architecture and conventions;
+- repository discovery plus consistent, accessible user-facing design;
+- semantic structure, readable naming, purposeful comments, and named domain constants;
+- focused testing, conservative dependency management, and meaningful validation;
+- durable planning, repository safety, and concise completion reporting.
+
+`project init` installs the template as a reference, not as a replacement for
+existing active guidance. During reconciliation, Codex merges only applicable
+rules into the project's `AGENTS.md` and preserves its local organization and
+adaptations.
+
 ## Commands
 
 | Action | Command |

package/assets/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,
@@ -137,16 +141,20 @@ conditional procedures into validated project skills.
 - Avoid broad commands. After changes, run the smallest targeted verification
   that meaningfully validates them when practical, then report the command and
   result. Use the repository's documented package manager and scripts.
-- For behavior changes and bug fixes, add or update the smallest focused
-  automated tests that meaningfully prevent regression when the repository has
-  an established test setup.
+- Select tests for regression value rather than exhaustive coverage. When the
+  repository has an established test setup, cover changed observable contracts,
+  reported regressions, meaningful boundaries, and plausible costly failures,
+  especially security, trust-boundary, or data-loss risks.
+- Use one representative case per equivalent behavior class. Skip redundant
+  permutations, implementation-detail assertions, and contrived or unreachable
+  states unless a requirement or past defect justifies them.
 - Treat existing tests as regression contracts. Preserve their assertions unless
   the requested behavior intentionally changes. When behavior changes, update
   only the affected tests and add coverage for the new contract; never weaken or
   delete tests merely to make the suite pass.
-- Do not introduce a test framework or create low-value tests solely to satisfy
-  this rule. If automated coverage is impractical, explain why and perform the
-  strongest targeted verification available.
+- Do not introduce a test framework solely to satisfy this rule. If automated
+  coverage is impractical, explain why and perform the strongest targeted
+  verification available.
 - Run the relevant focused tests after changing tested behavior.
 - When adding or updating dependencies, pin exact versions rather than ranges.
   With pnpm, use `pnpm add -E` (`--save-exact`).
@@ -184,7 +192,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.

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@iamdevlinph/codex-kit",
-	"version": "1.1.2",
+	"version": "1.1.4",
 	"description": "Portable Codex subagents and project AGENTS.md defaults.",
 	"type": "module",
 	"bin": {