@dotdotgod/codex 0.1.14 → 0.1.15

package/README.md

@@ -1,13 +1,15 @@
 # @dotdotgod/codex
 
-Codex adapter for dotdotgod's context curation workflow. It packages reusable skills that help Codex load curated project memory, plan from docs before implementation, and initialize the shared agent documentation scaffold.
+> **Change a file, know what else must be checked.**
+
+Codex adapter for dotdotgod's context curation workflow. It packages reusable skills that help Codex load curated project memory, plan from docs before implementation, and initialize the shared agent documentation scaffold so changes start with the right specs, tests, plans, and archive map.
 
 ## What Gets Better?
 
-- Codex can start from `AGENTS.md` and the dotdotgod docs map instead of rebuilding context manually.
+- Codex can start from `AGENTS.md` and the dotdotgod docs map.
 - Load guidance prefers `dotdotgod load-snapshot <root> --json` when the CLI is available, then falls back to README-index reads.
 - Codex can use docs structure as retrieval intent: specs for behavior, architecture for rationale, tests for verification, plans for current work, and archive indexes for past decisions.
-- Product intent, design rationale, and verification standards stay in durable docs instead of transient chat.
+- Product intent, design rationale, and verification standards stay in durable docs.
 - Planning work captures current intent in `docs/plan/<task-slug>/README.md` before implementation.
 - Completed plans and temporary reports use the same archive structure as Pi and Claude Code, turning outcomes into future context.
 - `dd:load`, `dd:plan`, and `dd:init` can be used as command-like trigger phrases where direct slash commands are unavailable.
@@ -48,6 +50,6 @@ pnpm --filter @dotdotgod/codex run pack:dry-run
 
 ## Compared with Graphify-Style Memory
 
-This adapter packages reusable workflow skills rather than a repo-wide extraction engine. It guides Codex to prefer a bounded dotdotgod load snapshot when available, avoid broad archive scans, and follow README indexes before reading raw files.
+This adapter packages reusable workflow skills. It guides Codex to prefer a bounded dotdotgod load snapshot when available, avoid broad archive scans, and follow README indexes before reading raw files.
 
 The strength is structured retrieval: project docs declare which files are rules, specs, architecture, verification, active intent, or historical memory. That keeps the memory layer portable across Codex runtimes and useful on small tasks where a large graph report would be overhead.

package/hooks/README.md

@@ -13,11 +13,17 @@ Use hooks only when you want opt-in reminders, lightweight validation, or local
 ## Opt-In Levels
 
 - `advisory`: print reminders or read-only status only.
-- `validate`: run `dotdotgod validate` after docs work or at stop time.
+- `validate`: run `dotdotgod validate . --include-local-memory --check-index` after docs work or at stop time.
 - `strict-plan-safety`: add local blocking scripts only when a reliable plan-only state signal exists.
 
 Start with advisory hooks. Do not enable blocking hooks until you have tested the hook payload, Codex trust state, and your local policy script.
 
+## Review Before First Run
+
+Codex may detect a configured hook but keep it disabled until you review it. If Codex shows `1 hook needs review before it can run. Open /hooks to review it.`, open `/hooks`, inspect the command, and approve only commands you trust.
+
+After approval, trigger a small supported edit such as an `apply_patch` documentation comment change and confirm the hook status message or command output appears. If the hook was added while a Codex session was already running, restart Codex before the smoke test so the current configuration is loaded.
+
 ## Advisory `hooks.json` Example
 
 This example reminds Codex to use dotdotgod intentionally at session start:
@@ -51,12 +57,12 @@ matcher = "Edit|Write|apply_patch"
 
 [[hooks.PostToolUse.hooks]]
 type = "command"
-command = "sh .codex/hooks/validate-docs-if-needed.sh"
+command = "dotdotgod validate . --include-local-memory --check-index"
 timeout = 120
-statusMessage = "Checking dotdotgod docs when relevant"
+statusMessage = "Checking dotdotgod docs and index freshness"
 ```
 
-Use validation hooks only by explicit opt-in. They are useful for docs-heavy sessions but can be noisy if they run after every supported edit. Prefer a local wrapper that filters to docs-related edits or writes validation logs without returning invalid hook output.
+Use validation hooks only by explicit opt-in. They are useful for docs-heavy sessions but can be noisy if they run after every supported edit. `--check-index` compares current markdown fingerprints with `.dotdotgod/manifest.json` without refreshing the cache; if the only failure is an index freshness error, run `dotdotgod index .` or `pnpm run verify:cache` intentionally.
 
 ## Prompt Reminder Pattern
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dotdotgod/codex",
-  "version": "0.1.14",
+  "version": "0.1.15",
   "description": "Codex adapter for dotdotgod project memory workflows.",
   "type": "module",
   "license": "MIT",

package/skills/project-initializer/references/agent-docs.md

@@ -20,6 +20,6 @@ Put durable, project-wide instructions in `AGENTS.md`:
 - coding and review expectations
 - environment constraints
 
-For projects using the dotdotgod CLI, `dotdotgod validate` is the enforcement point for machine-readable docs rules such as fenced `json dotdotgod` traceability blocks in behavior specs. Keep the detailed schema in the CLI and its validation errors rather than duplicating it across agent memory files.
+For projects using the dotdotgod CLI, `dotdotgod validate` is the enforcement point for machine-readable docs rules such as fenced `json dotdotgod` traceability blocks in behavior specs. Keep the detailed schema in the CLI and its validation errors.
 
 Do not duplicate the same body in `CLAUDE.md` and `CODEX.md`; duplication causes drift.

package/skills/project-load/SKILL.md

@@ -34,7 +34,7 @@ Do not modify files during the load pass unless the user explicitly asks for edi
    - `docs/plan/README.md`
    - `docs/archive/README.md`
 4. Start with `AGENTS.md`, `README.md`, and `docs/README.md` when they are not already clear from the CLI snapshot or loaded context.
-5. Follow README indexes. Read relevant docs under `docs/spec`, `docs/test`, and `docs/arch` selectively instead of re-scanning every listed file unless the task needs a full refresh.
+5. Follow README indexes. Read relevant docs under `docs/spec`, `docs/test`, and `docs/arch` selectively unless the task needs a full refresh.
 6. List `docs/plan` entries first, then selectively read only relevant active plans.
 7. Use `docs/archive/README.md` as the archive history map. Do not scan archive bodies by default; read targeted completed plans under `docs/archive/plan/` or reports under `docs/archive/report/` only when directly relevant.
 8. Avoid broad reads of generated outputs, dependencies, databases, caches, secrets, and `.env*` contents.