Distillation

🔴 (13:18) User stated /home/byk/Code/opencode-lore-v2 is a colocated Jujutsu repository containing both .jj/ and .git/; mutations must use jj, while Git tools are limited to read-only operations or unsupported tasks. 🔴 (13:18) User stated Jujutsu conflicts are first-class: jj never fails on conflict; operations record the conflict in the resulting commit, after which jj st must be checked and files resolved manually rather than with interactive jj resolve. 🔴 (13:18) User stated Jujutsu agent operations must never use interactive flags and commands that describe/commit must always pass -m "msg". 🔴 (13:18) User stated Jujutsu mutations such as squash, abandon, rebase, restore, and commit must be verified afterward with jj st and jj log. 🔴 (13:18) User stated Jujutsu change IDs should be preferred over commit IDs because change IDs survive rewrites; immutable commits such as tracked main must never be rebased or described directly. 🔴 (13:18) User stated Jujutsu recovery uses jj undo, jj op log, and jj op restore <op-id>; stale working copies are repaired with jj workspace update-stale. 🔴 (13:19) User stated Lore runs on Node.js >= 22.5 and is a TypeScript monorepo using pnpm workspaces, SQLite WAL mode, and FTS5; the production database is stored at ~/.local/share/lore/lore.db. 🔴 (13:19) User stated Lore tests use a temporary SQLite database configured by packages/core/test/setup.ts—never the production DB. 🔴 (13:19) User stated Lore has 4 workspace packages: @loreai/core at packages/core/, @loreai/gateway at packages/gateway/, @loreai/opencode at packages/opencode/, and @loreai/pi at packages/pi/. 🔴 (13:19) User stated release versions and CHANGELOG.md must never be bumped or edited manually; Sentry Craft handles both through GitHub Actions. 🔴 (13:19) User stated releases are triggered with gh workflow run release.yml -f version=auto or an explicit version such as gh workflow run release.yml -f version=0.23.0. 🔴 (13:19) User stated the release workflow: 1. runs scripts/bump-version.sh across all package.json versions, 2. generates the changelog from conventional commits, 3. creates and pushes release/X.Y.Z, 4. runs CI to build npm tarballs, standalone binaries, and delta patches, 5. opens a Craft “publish” issue whose accepted label triggers publishing, and 6. publishes npm packages through OIDC plus a GitHub Release with binaries and patches. 🔴 (13:19) User stated every adversarial-review defect must receive a deterministic regression test in the same PR that fails on the base branch, passes on the fix, and drives the real precondition. 🔴 (13:19) User stated tests of guards must fail when the guard is deleted; otherwise they do not actually test the guard. 🔴 (13:19) User stated bug fixes must follow failing-first TDD: write the regression test first, confirm it fails on the base branch, then confirm it passes after the fix—never trust the fix without seeing it fail. 🔴 (13:19) User stated adversarial state setup must place preexisting state before the operation under test and cover delete-then-recreate and modify-while-off lifecycle sequences. 🔴 (13:19) User stated skip and early-return branches such as NOT EXISTS, latest <> 'upsert', and content-match guards are the highest-risk review surface; each needs a test that makes it skip something incorrectly and proves it does not. 🔴 (13:19) User stated fan-out additions require corresponding parametrized contract coverage: SYNCED_TABLES in packages/core/test/sync-registry-contract.test.ts, MIGRATIONS through the db.test.ts schema-version assertion plus migration-specific tests, and AGENTS through agents.test.ts. 🔴 (13:19) User stated memoized arrays shared across callers should be frozen so accidental mutation raises TypeError in strict mode instead of silently corrupting the cache. 🔴 (13:19) User stated db().query monkeypatches are shadowed by the tracing Proxy; SQL-counting tests must use the log.registerSink({ withDbSpan }) seam. 🔴 (13:19) User stated non-trivial changes require two distinct review passes: 1. adversarial/correctness review and 2. security/pentest review; adversarial review is mandatory before merge, while security review depends on risk profile. 🔴 (13:19) User stated correctness-critical changes involving the sync engine, hashing, lifecycle, or migrations require adversarial review regardless of size.