@dotdotgod/codex 0.1.18 → 0.1.20

package/README.md

@@ -1,26 +1,38 @@
 # @dotdotgod/codex
 
-[![npm version](https://img.shields.io/npm/v/@dotdotgod/codex.svg)](https://www.npmjs.com/package/@dotdotgod/codex) [![GitHub](https://img.shields.io/badge/GitHub-dotdotgod%2Fdotdotgod-181717?logo=github)](https://github.com/dotdotgod/dotdotgod/tree/main/packages/codex) [![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](../../LICENSE)
+[![npm version](https://img.shields.io/npm/v/@dotdotgod/codex.svg)](https://www.npmjs.com/package/@dotdotgod/codex) [![GitHub](https://img.shields.io/badge/GitHub-dotdotgod%2Fdotdotgod-kit-181717?logo=github)](https://github.com/dotdotgod/dotdotgod-kit/tree/main/packages/codex) [![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](../../LICENSE)
 
 > **Change a file, know what else must be checked.**
 
-Codex adapter for dotdotgod's context curation workflow. It packages reusable skills that help Codex initialize shared agent docs, load bounded project memory, and plan from docs before implementation.
-
-Impact/context in practice:
+```bash
+$ dotdotgod graph impact . --changed packages/cli/src/core.mjs --compact
+```
 
 ```text
-dd:init creates the memory scaffold
-dd:load reads a bounded snapshot and relevant docs
-dd:plan captures durable task intent before implementation
+docs:
+- docs/spec/REFERENCE_EXPANSION.md (91; incoming:implemented_by, semantic_similarity)
+- docs/test/REFERENCE_EXPANSION.md (65.3; verified_by, semantic_similarity)
+- docs/spec/LOAD_PROJECT.md (35.8; related_doc, semantic_similarity)
+
+tests:
+- packages/cli/test/core.test.mjs (78.6; semantic_similarity, incoming:semantic_similarity, verified_by)
+- packages/cli/test/e2e.test.mjs (51.4; verified_by)
+
+files:
+- packages/cli/src/core.mjs (100; changed-file)
+- packages/pi/extensions/plan-mode/index.ts (45; implemented_by, semantic_similarity)
 ```
 
-The same project-memory graph that powers `dotdotgod graph impact` can surface likely related docs, tests, source, and config for changed files. The graph is not only traceability: it also uses Markdown links, README routes, headings, package metadata, memory-area membership, commands, tests, and deterministic routing hints.
+`graph impact` ranks the specs, tests, architecture notes, config docs, and source files most likely to matter for a change. `--compact` keeps the result agent-facing: grouped by docs/tests/files and annotated with the reasons each item is likely relevant. It uses the project-memory graph built from Markdown links, README routes, headings, traceability blocks, package metadata, memory areas, and deterministic routing hints.
+
+Codex adapter for dotdotgod's context curation workflow. It packages reusable skills that help Codex initialize the fixed load-context surface, load bounded project memory, and plan from explicit maintained graph links before implementation.
 
 ## What Gets Better?
 
 - 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.
+- Planning guidance encourages agents to keep README routes, traceability blocks, plans, and archives current so `graph impact` remains useful.
 - 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.
@@ -70,8 +82,8 @@ pnpm --filter @dotdotgod/codex run pack:dry-run
 
 ## Learn More
 
-See the [root README](../../README.md), [GitHub repository](https://github.com/dotdotgod/dotdotgod), [`docs/concept/CONTEXT_CURATION.md`](../../docs/concept/CONTEXT_CURATION.md), [`docs/concept/CONTEXT_MECHANICS.md`](../../docs/concept/CONTEXT_MECHANICS.md), [`docs/spec/MEMORY_AREA_CONFIG.md`](../../docs/spec/MEMORY_AREA_CONFIG.md), and [`docs/spec/TRACEABILITY_CONFIG.md`](../../docs/spec/TRACEABILITY_CONFIG.md).
+See the [root README](../../README.md), [GitHub repository](https://github.com/dotdotgod/dotdotgod-kit), [`docs/concept/CONTEXT_CURATION.md`](../../docs/concept/CONTEXT_CURATION.md), [`docs/concept/CONTEXT_MECHANICS.md`](../../docs/concept/CONTEXT_MECHANICS.md), [`docs/spec/MEMORY_AREA_CONFIG.md`](../../docs/spec/MEMORY_AREA_CONFIG.md), and [`docs/spec/TRACEABILITY_CONFIG.md`](../../docs/spec/TRACEABILITY_CONFIG.md).
 
 ## Compared with Graphify-Style Memory
 
-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 from project-declared memory, not a giant graph report.
+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 from explicit project-maintained links and the fixed docs surface, not a giant graph report.

package/hooks/README.md

@@ -8,6 +8,7 @@ Use hooks only when you want opt-in reminders, lightweight validation, or local
 
 - Use `dd:load` or the `project-load` skill when you intentionally want a curated project-memory load.
 - Use `dd:plan` or the `doc-first-planning` skill before implementation, refactors, migrations, or multi-step work.
+- During planning, prefer bounded dotdotgod context/status helpers: `status`, `load-snapshot`, `resolve`, `expand`, `graph impact`, `graph communities`, read-only `config`, and intentional `index` refreshes. Do not run mutating scaffold/config commands such as `init` or `config init` from hooks unless the user explicitly requested that setup.
 - Use hooks for small reminders at session start, prompt submission, supported tool boundaries, or stop time.
 
 ## Opt-In Levels
@@ -118,6 +119,7 @@ A strict script must read hook JSON from stdin, confirm the session is explicitl
 
 - Do not run `pnpm run verify` after every tool call.
 - Do not run `dotdotgod index` as an automatic stop hook.
+- Do not run `dotdotgod init` or `dotdotgod config init` automatically.
 - Do not move active plans to `docs/archive/` automatically.
 - Do not block all source writes without an explicit plan-only state signal.
 - Do not imply Codex has Claude/Pi slash-command parity.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dotdotgod/codex",
-  "version": "0.1.18",
+  "version": "0.1.20",
   "description": "Codex adapter for dotdotgod project memory workflows.",
   "type": "module",
   "license": "MIT",
@@ -31,13 +31,13 @@
     "README.md",
     "LICENSE"
   ],
-  "homepage": "https://github.com/dotdotgod/dotdotgod/tree/main/packages/codex#readme",
+  "homepage": "https://github.com/dotdotgod/dotdotgod-kit/tree/main/packages/codex#readme",
   "repository": {
     "type": "git",
-    "url": "git+https://github.com/dotdotgod/dotdotgod.git",
+    "url": "git+https://github.com/dotdotgod/dotdotgod-kit.git",
     "directory": "packages/codex"
   },
   "bugs": {
-    "url": "https://github.com/dotdotgod/dotdotgod/issues"
+    "url": "https://github.com/dotdotgod/dotdotgod-kit/issues"
   }
 }

package/skills/doc-first-planning/SKILL.md

@@ -36,6 +36,7 @@ Prefer live repository docs in this order:
    - Read nearest README indexes and relevant focused docs.
    - For behavior changes, prefer specs with CLI-enforced fenced `json dotdotgod` traceability blocks in the final section; use their source, test, related-doc, and verification-command mappings before editing code.
    - When the dotdotgod CLI is available and likely target files are known, run `dotdotgod graph impact <root> --changed <path> --compact --json` for a small bounded set of those files. Use the related specs, tests, docs, commands, scores, and reasons to strengthen target files, risks, and verification steps. If impact lookup fails or the CLI is unavailable, continue with README-index and traceability fallback evidence.
+   - During planning, treat these dotdotgod commands as bounded context/status helpers: `status`, `load-snapshot`, `resolve`, `expand`, `graph impact`, `graph communities`, read-only `config`, and `index`. Do not run mutating scaffold/config commands such as `init` or `config init` unless the user explicitly asks for initialization or config creation.
    - Use `grep` or `find` after reference expansion, impact, and targeted reads when the task needs fallback discovery or raw source text search.
    - Read code only after docs identify likely module boundaries, impact output points to relevant files, or docs are missing/stale.
 3. Create or update the active plan at:

package/skills/project-initializer/scripts/init_project.sh

@@ -293,6 +293,8 @@ Dotdot code conventions for keeping implementation simple and maintainable.
 - Do not abstract code that is not reused.
 - If code grows beyond 150 lines, consider splitting or extracting focused units even when it is not reused.
 - Review files approaching 250 lines for focused extraction by responsibility.
+- Treat repeated \`dotdotgod graph impact\` results that collapse onto one large file as a design signal to split mixed responsibilities by behavior.
+- Dotdotgod impact reveals hotspots but does not replace focused module boundaries.
 - Prefer extracting pure helpers when behavior can be tested without runtime dependencies.
 - Keep runtime integration explicit and local until a stable reuse pattern appears.
 - Do not abstract reused code when the reused behavior is likely to split into separate features or flows later.

package/skills/project-load/SKILL.md

@@ -22,6 +22,7 @@ Do not modify files during the load pass unless the user explicitly asks for edi
    - If `dotdotgod` is installed or available in the repository, run `dotdotgod load-snapshot <root> --json`.
    - If the local environment allows package execution but no `dotdotgod` binary is available, optionally run `npx @dotdotgod/cli load-snapshot <root> --json`.
    - Treat the snapshot as the first-pass project-memory map for cache status, graph size, memory areas, related communities, and archive inclusion policy.
+   - During load/planning, treat `dotdotgod status`, `load-snapshot`, `resolve`, `expand`, `graph impact`, `graph communities`, read-only `config`, and `index` as bounded context/status helpers. Avoid mutating scaffold/config commands such as `init` or `config init` unless the user explicitly asks for initialization or config creation.
    - Use `dotdotgod graph impact <root> --changed <path> --compact --json` as a task-focused impact map when the user identifies a likely source/config/doc file.
    - Use `grep` or `find` after `expand`, impact, and targeted reads when the task needs fallback discovery or raw source text search.
    - Fall back to raw `dotdotgod graph impact <root> --changed <path> --json` only when diagnostics need the full payload.