Distillation

Date: Sep 16, 2026

• 🔴 [requested-review] (20:03) User requested an exhaustive read-only validation of immutable candidate /home/byk/Code/opencode-lore-responses-reference-v2; explicitly prohibited edits, formatting, installs, VCS mutations, server startup, network access, production DB access, and fixes.
• 🔴 (20:03) User specified candidate identity: base commit 2cbf40060c67df229731cf1b9e34d5bf22ec2145; head stable change wywumkptssoy; head commit 8063355cb328.
• 🔴 (20:03) User specified expected plain diff SHA-256 007a15b7fd1bcf9b346d89911b2353098b6fec408c12d3b6fcc24a498a37a356.
• 🔴 (20:03) User specified expected bundle SHA-256 fd9415c36517f241a744e310942915f87cf68a8ec8d6b2feeb57294e18c238a6.
• 🔴 (20:03) User required reading repository instructions/scripts and verifying: a clean empty child, candidate identity and conflict state, exactly 2 changed files and the expected diff hash, bundle artifacts and hash, no remaining workers, and unchanged final identity/hash.
• 🔴 [requested-tests] (20:03) User required running the full test command with sufficient timeout: CI=1 NO_COLOR=1 SENTRY_AUTH_TOKEN= SENTRY_ENABLED=0 pnpm test -- --printConsoleTrace.
• 🔴 [requested-tests] (20:03) User required all four deterministic test shards if the full test run is inconclusive or exits nonzero because of infrastructure; required exact test counts, proof of temporary DB use, and confirmation that every test file runs exactly once across the fallback shards.
• 🟡 (20:03) Assistant stated the required repo-setup skill was unavailable and would instead apply repository instructions directly, use Jujutsu only for VCS inspection, and keep the candidate read-only.
• 🔴 (20:03) User-provided Jujutsu guidance states: “jj never fails on conflict.” Conflicts are recorded in the resulting commit and must be detected with jj st; jj resolve is prohibited because it is interactive.
• 🔴 (20:03) User-provided Jujutsu rules require using jj, not git, when .jj/ exists; mutations in colocated .jj/ + .git/ repositories must go through jj, while Git is permitted only for read-only operations or capabilities unavailable in jj.
• 🔴 (20:03) User-provided Jujutsu rules prohibit interactive flags such as -i/--interactive, require -m "msg" for describe/commit operations, require verification with jj st and jj log after mutations, prefer stable letter-based change IDs over hexadecimal commit IDs, and prohibit rebasing or describing immutable tracked commits.
• 🟡 (20:03) Candidate root contained exactly 28 entries: .craft.yml, .git, .github/, .gitignore, .jj/, .lore.md, .oxfmtrc.json, .oxlintrc.json, AGENTS.md, CHANGELOG.md, codecov.yml, LICENSE, node_modules/, package.json, packages/, patches/, pnpm-lock.yaml, pnpm-workspace.yaml, quality/, README.md, scripts/, stryker.config.mjs, supabase/, tsconfig.base.json, tsconfig.json, vitest.config.ts, vitest.evals.config.ts, vitest.mutation.config.ts.
• 🟡 (20:03) AGENTS.md describes Lore as a TypeScript monorepo using pnpm workspaces, requiring Node.js >= 22.5, with SQLite in WAL mode and FTS5; the normal DB path is ~/.local/share/lore/lore.db.
• 🟡 (20:03) AGENTS.md defines four packages: @loreai/core at packages/core/ (shared memory engine), @loreai/gateway at packages/gateway/ (transparent LLM proxy and lore CLI), @loreai/opencode at packages/opencode/ (OpenCode plugin adapter), and @loreai/pi at packages/pi/ (Pi coding-agent extension adapter).
• 🟡 (20:03) Repository review policy is in quality/REVIEW.md; every non-trivial PR requires an adversarial correctness review before merge, with regression-test discipline, adversarial-order state setup, fan-out registry coverage, recurring bug-class batteries, and a two-reviewer rule.
• 🟡 (20:03) Lore’s three-tier architecture is: Tier 1 temporal storage in packages/core/src/temporal.ts; Tier 2 distillation in packages/core/src/distillation.ts, including segments capped at 16K tokens and meta-distillation when gen-0 count exceeds 20; Tier 3 gradient context management in packages/core/src/gradient.ts, with Layer 0 full passthrough, Layer 1 distilled prefix plus compressed raw content, Layer 2 aggressive tool-output stripping, and Layer 3 emergency compression.
• 🟡 (20:03) 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.
• 🟡 (20:03) Knowledge creation paths are ordered as: 1. LLM Curator in packages/core/src/curator.ts; 2. regex-based Pattern Extraction in packages/core/src/pattern-extract.ts; 3. File Import from .lore.md in packages/core/src/agents-file.ts; 4. curator.ts consolidate() when entries exceed maxEntries of 25.
• 🔴 (20:03) Repository tests use a temporary SQLite DB through packages/core/test/setup.ts—never the production DB.
• 🔴 (20:03) Repository release policy: “Never manually bump versions or edit CHANGELOG.md.” Sentry Craft and GitHub Actions handle version updates and changelog generation automatically.
• 🟡 (20:03) Release commands documented in AGENTS.md 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.
• 🟡 (20:03) Release workflow order is: 1. scripts/bump-version.sh updates all package.json versions; 2. changelog is generated from conventional commits; 3. a release/X.Y.Z branch is created and pushed; 4. CI runs tests and builds npm tarballs, standalone binaries, and delta patches; 5. Craft opens a publish issue and the accepted label triggers Publish; 6. Publish uses npm OIDC trusted publishing and creates a GitHub Release with binaries and patches.
• 🟡 (20:04) Root package.json identifies lore-monorepo, uses pnpm@10.28.0, and defines "test": "vitest run" and "build": "pnpm -r run build".