peaks-loop 4.1.1 → 4.1.2

package/skills/peaks-audit/SKILL.md

@@ -56,7 +56,7 @@ The `.peaks/` workspace is partitioned by a **single scope axis** (session-id, a
 When a workflow surfaces a human need (a sentence, a ticket summary, a voice note, a vague "I want X"), call `peaks-audit` BEFORE any other skill:
 
 ```text
-need expressed  →  peaks audit-goal  →  (user accepts goal)  →  peaks-prd  →  peaks-rd  →  peaks-qa
+need expressed  →  peaks audit goal  →  (user accepts goal)  →  peaks-prd  →  peaks-rd  →  peaks-qa
                        ▲
                        │
               you are here on first contact
@@ -80,14 +80,14 @@ Do NOT invoke peaks-audit when the user is asking for a code review, a test run,
 ### Intended CLI form (L2.4 — not yet registered in `src/cli/commands/audit-commands.ts`)
 
 ```bash
-peaks audit-goal --need "<natural language description of the need>" --json
+peaks audit goal --need "<natural language description of the need>" --json
 ```
 
 > **Deviation note:** at the time of this writing, only `peaks audit red-lines` and `peaks audit static` are registered as `peaks audit` subcommands. The `audit-goal` subcommand is **not yet wired** in `src/cli/commands/audit-commands.ts`. Callers reach the primitive through the TypeScript module below. The CLI registration is tracked separately and must not be conflated with the primitive itself.
 
 ### Service-layer form (authoritative, used today)
 
-`peaks audit-goal` is a thin wrapper around the `auditGoal()` function in `src/services/audit/audit-goal-service.ts`. Two integration paths exist today:
+`peaks audit goal` is a thin wrapper around the `auditGoal()` function in `src/services/audit/audit-goal-service.ts`. Two integration paths exist today:
 
 **1. Direct TypeScript call** (used by `src/services/final-review/final-review-service.ts`, `src/services/slice/llm-arbitrator.ts`, `src/services/slice/multi-pass-orchestrator.ts`):
 

package/dist/services/codegraph/codegraph-include-reconciler.d.ts

@@ -1,10 +0,0 @@
-export type CodegraphIncludeNormalizePlan = {
-    readonly changed: boolean;
-    readonly include: readonly string[];
-    readonly addedPatterns: readonly string[];
-};
-export declare function normalizeCodegraphInclude(input: {
-    readonly include: readonly string[];
-    readonly candidateExtensions: readonly string[];
-}): CodegraphIncludeNormalizePlan;
-export declare function upstreamUnnamedIncludeExtensions(): readonly string[];

package/dist/services/codegraph/codegraph-include-reconciler.js

@@ -1,160 +0,0 @@
-// src/services/codegraph/codegraph-include-reconciler.ts
-//
-// Slice-002 of `2026-09-16-codegraph-index-integrity` — the INCLUDE axis
-// of the config repair. It answers one question:
-//
-//   "Which extensions does upstream's extractor support but upstream's own
-//    default `include` template never names, and which of those does THIS
-//    project's `include` still not admit?"
-//
-// Why this exists (the real defect, measured): upstream
-// `@colbymchenry/codegraph` decides what to parse from its own
-// `EXTENSION_MAP` (37 extensions in 0.7.10), but `init` writes a 32-entry
-// `DEFAULT_CONFIG.include` template that names only 32 of them. Five
-// supported extensions are therefore absent from every fresh config:
-// `.mjs`, `.cjs`, `.pyw`, `.hxx`, `.rake`. Upstream's `mergeConfig` has no
-// separate override channel — `config.json`'s `include` replaces the
-// defaults wholesale — so a fresh clone indexes none of them while
-// `peaks codegraph status` still prints `[OK] Index is up to date`. On this
-// repo that was 31 tracked files (30 `.mjs` + 1 `.cjs`) absent from a
-// 1220-row index. It is the same class of defect as upstream's default
-// `exclude` template colliding with real source directories, which slice S2
-// of `2026-09-12-codegraph-exclude-integrity` already self-heals at the
-// `init` seam; the include axis was simply never reconciled.
-//
-// Genericity (binding — mirrors the exclude reconciler): no hardcoded
-// extension list, no hardcoded rule names, no project-specific paths. The
-// candidate set is COMPUTED from upstream's own two tables (`EXTENSION_MAP`
-// in `dist/extraction/grammars.js`, `DEFAULT_CONFIG` in `dist/types.js`),
-// and every candidate is confirmed against upstream's own decision pair
-// (`isLanguageSupported(detectLanguage(...))` — the same two functions
-// `extraction/index.js` calls). Upstream can add an extension tomorrow and
-// this module picks it up with no edit here; the "five" above is a
-// measurement, not a constant in the code.
-//
-// Additive, never clobbering: a project's `include` is append-only from
-// here. No user entry is removed, reordered or rewritten, and an extension
-// any existing entry already admits is left alone. Append-only is the same
-// posture `codegraph-exclude-repair.ts` takes toward a third-party config
-// file it edits.
-//
-// Scope: PURE (`normalizeCodegraphInclude`) plus ONE read-only adapter
-// (`upstreamIncludeCandidateExtensions`, which reads the installed upstream
-// package). Nothing in this module writes a file.
-//
-// NOTE FOR FUTURE EDITORS: glob literals contain the two-character
-// sequence that ends a block comment, so every comment in this file uses
-// `//` lines — INCLUDING the exported API documentation, which is why this
-// file has no `/** ... */` blocks. Do not convert them.
-import { createRequire } from 'node:module';
-import { dirname, extname, join } from 'node:path';
-import { compileCodegraphGlobs } from './codegraph-exclude-reconciler.js';
-// ─────────────────────────────────────────────────────────────────────
-// Which extensions does this project's `include` already admit?
-// ─────────────────────────────────────────────────────────────────────
-// The pattern upstream's own template uses for a bare extension: all 32
-// entries of `DEFAULT_CONFIG.include` have exactly this shape, and they are
-// matched with `picomatch(..., { dot: true })` — the same engine, and the
-// same options, that `matchesCodegraphGlob` delegates to. So an appended
-// pattern is indistinguishable in form from an upstream-authored one.
-function includePatternForExtension(extension) {
-    return `**/*${extension}`;
-}
-// A synthetic path used ONLY to ask "does any existing rule admit a file
-// with this extension". A root-level probe answers that question exactly
-// for every pattern shape upstream itself writes, because `picomatch`'s
-// trailing-slash-star-star prefix matches zero path segments (measured:
-// the `.mjs` pattern matches both `probe.mjs` and `a/b/probe.mjs`).
-//
-// KNOWN PROXY LIMIT, stated rather than hidden: a path-narrowed rule such as
-// a `src`-prefixed brace list of js/mjs does NOT match the root-level probe,
-// so an extension admitted only under a subdirectory is treated as
-// uncovered and the bare extension pattern is appended. That errs ADDITIVE —
-// the index admits more tracked files, never fewer — and it is pinned by a
-// test rather than left to be discovered. A false "already covered" cannot
-// occur for any pattern upstream's template can produce, and if it did its
-// only effect would be to leave the gap the inspector already reports.
-function extensionProbePath(extension) {
-    return `codegraph-include-probe${extension}`;
-}
-// Compiled ONCE per rule, never per (candidate x rule) pair — see
-// `compileCodegraphGlobs`. The `matchers` list is the include list the
-// candidate is tested against: the caller's entries first, then the
-// patterns this same pass has already decided to append, so a duplicate
-// candidate cannot append twice without re-parsing the list each time
-// (perf audit S10: the re-parse was 0.25 / 2.15 / 23.4 / 234.4 ms at
-// 32 / 320 / 3,200 / 32,000 rules, plus a spread array per candidate).
-function isExtensionAdmitted(extension, matchers) {
-    const probe = extensionProbePath(extension);
-    return matchers.some((matcher) => matcher.matchesAny(probe));
-}
-// Pure: given the current `include` list and the extensions upstream
-// supports but its own template omits, return the list with the uncovered
-// ones appended. No fs, no clock, no serialization.
-//
-// The result is always a SUPERSET of the input, in the input's order, so a
-// caller can never remove or reorder a user entry. Appending an extension
-// the list already admits is a no-op, which is what makes the whole
-// normalization idempotent: feeding the repaired list back in yields
-// `changed: false`.
-//
-// Candidates are de-duplicated by their EFFECT, not by string equality:
-// each candidate is tested against the input list PLUS the patterns this
-// call has already appended, so a duplicate candidate cannot append twice.
-export function normalizeCodegraphInclude(input) {
-    const addedPatterns = [];
-    // The include list as this pass sees it, compiled once. Appending a
-    // pattern extends the list by ONE compiled rule instead of re-parsing
-    // every entry on the next candidate (see `isExtensionAdmitted`).
-    const matchers = [compileCodegraphGlobs(input.include)];
-    for (const candidate of input.candidateExtensions) {
-        const extension = candidate.startsWith('.') ? candidate : `.${candidate}`;
-        if (isExtensionAdmitted(extension, matchers)) {
-            continue;
-        }
-        const pattern = includePatternForExtension(extension);
-        addedPatterns.push(pattern);
-        matchers.push(compileCodegraphGlobs([pattern]));
-    }
-    if (addedPatterns.length === 0) {
-        return { changed: false, include: input.include, addedPatterns: [] };
-    }
-    return {
-        changed: true,
-        include: [...input.include, ...addedPatterns],
-        addedPatterns
-    };
-}
-let cachedCandidateExtensions = null;
-// The extensions upstream's extractor supports but its own default
-// `include` template never names, as dotted extensions — measured against
-// the installed `@colbymchenry/codegraph` 0.7.10 as `.mjs`, `.cjs`,
-// `.pyw`, `.hxx`, `.rake`, in that order.
-//
-// Derived entirely from upstream's own data:
-//
-//   1. `EXTENSION_MAP` keys are the extension universe the extractor knows.
-//   2. The extensions upstream's template already names are read off
-//      `DEFAULT_CONFIG.include` — the entry's own extension, so the
-//      comparison is extension-to-extension and cannot be confused by a
-//      template that switches glob syntax.
-//   3. A candidate is kept only when upstream's own support decision
-//      accepts it, so a table entry with no grammar behind it is never
-//      repaired into the config.
-//
-// Returns the same array on every call (module-level cache); the two
-// modules only define tables and functions, so the load is cheap and
-// Node's `require` cache makes later calls free.
-export function upstreamUnnamedIncludeExtensions() {
-    if (cachedCandidateExtensions === null) {
-        const require = createRequire(import.meta.url);
-        const packageJsonPath = require.resolve('@colbymchenry/codegraph/package.json');
-        const distDir = join(dirname(packageJsonPath), 'dist');
-        const types = require(join(distDir, 'types.js'));
-        const grammars = require(join(distDir, 'extraction', 'grammars.js'));
-        const namedByTemplate = new Set(types.DEFAULT_CONFIG.include.map((entry) => extname(entry).toLowerCase()));
-        cachedCandidateExtensions = Object.keys(grammars.EXTENSION_MAP).filter((extension) => !namedByTemplate.has(extension.toLowerCase()) &&
-            grammars.isLanguageSupported(grammars.detectLanguage(`probe${extension}`)));
-    }
-    return cachedCandidateExtensions;
-}