Distillation

Date: Sep 16, 2026

• 🟡 [requested-validation] (22:19) User requested read-only exhaustive validation of immutable Codex candidate /home/byk/Code/opencode-lore-codex-reasoning: exact child change wlpsntppxyyxpvwnnywkpvkskzvtktvp, commit b588d81bfd33e0b30e5040c694c893b3a116e363; parent rtwyxzrr, commit b9feb17a1feb58a72a080cca0e493130427c506f; expected diff SHA 8553e8714cf769789ec17e29f4ae2d3ade02d5cbd8662e1ef33981871dcd15a7; expected changes exactly pipeline.ts and the recall-aware test.
• 🔴 [enforced-read-only-validation] (22:19) User prohibited editing, formatting, installing, VCS mutations, network access, server use, and production DB access during validation.
• 🔴 [requested-integrity-checks] (22:19) User required identity, status, conflicts, and hash verification at both the start and end of validation.
• 🔴 [requested-tests] (22:19) User required the exact full test command CI=1 NO_COLOR=1 SENTRY_AUTH_TOKEN= SENTRY_ENABLED=0 pnpm test -- --printConsoleTrace with sufficient timeout.
• 🔴 [specified-test-fallback] (22:19) User required that if the full run is inconclusive, hits a harness timeout, or has a worker error, validation must run deterministic 4 shards, each exactly once, and aggregate their results.
• 🔴 [requested-validation-evidence] (22:19) User required verification of temporary DB isolation, bundle artifacts/hash, absence of workers, and a clean stable hash; final output must report exact counts, durations, exit codes, and PASS/FAIL.
• 🔴 (22:19) User stated: “Never warning-only; use lore recall/local UI fallback.”
• 🔴 (22:23) User stated that jj never fails on conflict: after rebase/new/squash, conflicts are recorded in the resulting commit and must be detected with jj st, resolved manually without interactive jj resolve, and confirmed cleared via jj st.
• 🔴 (22:23) Project uses Jujutsu because .jj/ exists; mutations must use jj, not git, even though the repository is colocated with both .jj/ and .git/.
• 🔴 (22:23) Jujutsu workflow rules: never use interactive flags; always pass -m "msg" when describing/committing; verify mutations using jj st and jj log; prefer stable letter-based change IDs over hexadecimal commit IDs; never rebase or describe an immutable commit; use jj undo or jj op restore <op-id> for recovery.
• 🟡 (22:23) Repository root /home/byk/Code/opencode-lore-codex-reasoning contained 28 entries, including .git, .jj/, .lore.md, AGENTS.md, CHANGELOG.md, node_modules/, package.json, packages/, patches/, quality/, scripts/, supabase/, vitest.config.ts, vitest.evals.config.ts, and vitest.mutation.config.ts.
• 🔴 (22:24) Project AGENTS.md requires every non-trivial PR to receive an adversarial correctness review before merge, following quality/REVIEW.md.
• 🔴 (22:24) Lore is a TypeScript/pnpm-workspaces monorepo requiring Node.js >=22.5; it implements a three-tier AI-agent memory architecture backed by SQLite in WAL mode with FTS5, normally stored at ~/.local/share/lore/lore.db.
• 🔴 (22:24) Lore packages are: @loreai/core at packages/core/ for the shared memory engine; @loreai/gateway at packages/gateway/ for the transparent LLM proxy and lore CLI; @loreai/opencode at packages/opencode/ for OpenCode lifecycle hooks; and @loreai/pi at packages/pi/ for the Pi extension adapter.
• 🔴 (22:24) Lore’s three memory tiers are: 1. temporal storage in packages/core/src/temporal.ts; 2. distillation in packages/core/src/distillation.ts, with segments capped at 16K tokens and meta-distillation after gen-0 count exceeds 20; 3. the four-layer gradient context manager in packages/core/src/gradient.ts.
• 🔴 (22:24) Knowledge entries in packages/core/src/ltm.ts use categories decision, pattern, preference, architecture, and gotcha; fields are id (UUIDv7), project_id, category, title, content (maximum 1200 characters), confidence (0.0–1.0), and cross_project.
• 🔴 (22:24) LTM creation paths are: 1. LLM curator in packages/core/src/curator.ts; 2. regex pattern extraction in packages/core/src/pattern-extract.ts; 3. .lore.md import in packages/core/src/agents-file.ts; 4. curator.ts consolidate() when entry count exceeds maxEntries of 25.
• 🔴 (22:24) Key packages/core/src/ltm.ts APIs are create(), update(), remove(), forSession(), search(), and searchScored(); search uses FTS5 BM25 with a LIKE fallback.
• 🔴 (22:24) .lore.md entries use <!-- lore:UUID --> markers and are sorted alphabetically by title within category. exportLoreFile() skips writes when the content hash is unchanged; importLoreFile() updates a known changed UUID or creates an unknown UUID; shouldImportLoreFile() checks mtime and then content hash.
• 🔴 (22:24) Tests use temporary SQLite databases through packages/core/test/setup.ts and never the production DB.
• 🔴 (22:24) Gateway build code is packages/gateway/script/build.ts, which produces a CJS bundle; script/bundle.ts creates a standalone binary. Core build code is packages/core/script/build.ts, producing Node.js-compatible CJS output.
• 🔴 (22:24) User stated: “Never manually bump versions or edit CHANGELOG.” Releases use Sentry Craft via GitHub Actions, which handles package versions and changelog generation automatically.
• 🔴 (22:24) Release workflow commands are gh workflow run release.yml -f version=auto for conventional-commit-derived semver or gh workflow run release.yml -f version=0.23.0 for an explicit version.
• 🔴 (22:24) Release workflow order is: 1. run scripts/bump-version.sh; 2. generate changelog from conventional commits; 3. create and push release/X.Y.Z; 4. CI tests and builds npm tarballs, standalone binaries, and delta patches; 5. Craft opens a publish issue; 6. labeling it accepted triggers npm OIDC publishing and a GitHub Release with binaries and patches.
• 🔴 (22:25) User stated the project follows TDD failing-first regression discipline: a bug regression test must first fail on the base branch and then pass with the fix.
• 🔴 (22:25) User stated: “Never trust the fix without seeing it fail.”
• 🔴 (22:25) Project review requires skip/early-return branch coverage, lifecycle-sequence coverage, fan-out registry coverage, delete-then-recreate sequences across lifecycle boundaries, apply-then-revert mutant checks, and property-test stability across 10 runs.
• 🔴 (22:25) Project review output must provide structured evidence and an overall MERGE or DO-NOT-MERGE; an unstructured “LGTM” is not acceptable.
• 🔴 (22:26) Root package.json identifies package lore-monorepo, uses "type": "module", package manager pnpm@10.28.0, Volta Node 24.16.0, Volta pnpm 10.28.0, and workspaces packages/*.
• 🔴 (22:26) Root test scripts are "test": "vitest run" and "pretest": "pnpm --filter @loreai/gateway run bundle"; coverage uses pnpm --filter @loreai/gateway run bundle && vitest run --coverage.
• 🔴 (22:26) Root quality/build scripts include pnpm -r run typecheck, pnpm -r run build, oxlint --type-aware, oxlint --type-aware --fix, oxfmt, oxfmt --check, vitest run --config vitest.evals.config.ts, and stryker run.
• 🔴 (22:26) Root package configuration permits built dependencies esbuild, onnxruntime-node, and sharp; patches @sentry/node@10.56.0 via patches/@sentry__node@10.56.0.patch; and runs pnpm --filter @loreai/gateway run build on postinstall.