feat: TraceDecay V2 delivery (PR8–PR13) + daemon performance, memory, and reliability overhaul

.cargo/config.toml

@@ -27,12 +27,46 @@ TRACEDECAY_DISABLE_GLOBAL_DB = { value = "1", force = false }
 # in-process. Installed binaries run outside cargo and are unaffected, but the
 # profile does apply to `cargo run` — use the installed binary (or set
 # TRACEDECAY_DATA_DIR yourself) for real `daemon install-service` runs.
-# Enforced by tests/test_profile_isolation_test.rs.
+# Enforced by crates/tracedecay-cli/tests/core_cli_suite/test_profile_isolation_test.rs.
 TRACEDECAY_DATA_DIR = { value = "target/test-profile/.tracedecay", force = false, relative = true }
 
+# Cheaper Linux debuginfo handling, scoped to the gnu triples so Windows
+# (MSVC supports only packed split-debuginfo) and macOS (already defaults to
+# unpacked) keep their platform defaults. `split-debuginfo=unpacked` leaves
+# debuginfo in the object files instead of linking it into every binary; it
+# is linker-agnostic and a no-op for profiles that build without debuginfo.
+# Deliberately no linker flags here: rustc already links
+# x86_64-unknown-linux-gnu with its bundled rust-lld, CI symlinks ld -> mold
+# (see .github/actions/setup-linux-mold; `-fuse-ld=mold` needs GCC >= 12),
+# and driver-only flags such as `-B` would land on the raw linker command
+# line — and fail — for anyone who sets `target.<triple>.linker` or
+# CARGO_TARGET_<TRIPLE>_LINKER to a linker executable directly. Developers
+# who want mold locally opt in through their own linker config or RUSTFLAGS
+# (a user-set RUSTFLAGS env var replaces these flags entirely).
+# Hotpath lanes that need --cfg tokio_unstable must source
+# scripts/hotpath-rustflags.sh so the env still carries mold and
+# unpacked split-debuginfo.
+[target.x86_64-unknown-linux-gnu]
+rustflags = ["-C", "split-debuginfo=unpacked"]
+
+[target.aarch64-unknown-linux-gnu]
+rustflags = ["-C", "split-debuginfo=unpacked"]
+
 [alias]
-# Local default for the full Rust test suite. Requires cargo-nextest:
+# Full Rust test suite. Requires cargo-nextest:
 # https://nexte.st/docs/installation/pre-built-binaries/
-test-all = "nextest run --workspace --no-fail-fast"
-test-ci = "nextest run --workspace --no-fail-fast"
-dogfood = "run --quiet --release --bin tracedecay -- dogfood"
+# Both aliases build with the perf cargo profile, which keeps the
+# critical-path kernels (code index, graph, sha2, …) optimized for the
+# generation-scale suites; see [profile.perf] in the root Cargo.toml.
+#
+# `test-ci` is the hosted acceptance selection: nextest's `ci` policy
+# (.config/nextest.toml: fail-fast off, one retry that still fails flaky
+# results, 8 threads, slow-timeout termination) and only the root fixture
+# feature. `.github/workflows/ci.yml` runs this exact alias, and its support
+# binaries/archives are built with `--profile perf` so they share artifacts
+# with it. Extra flags append: `cargo test-ci --locked -E 'binary(=x)'`.
+test-ci = "nextest run --workspace --profile ci --features tracedecay/test-helpers --cargo-profile perf"
+# Deliberately broader than CI: every optional feature (test-transport
+# acceptance suites, hotpath, …) under the same cargo profile, with the
+# default nextest policy (no retries).
+test-all = "nextest run --workspace --all-features --no-fail-fast --cargo-profile perf"

.changeset/v2-foundation-crates.md

@@ -0,0 +1,5 @@
+---
+"tracedecay": patch
+---
+
+Land the stacked V2 foundation: ten workspace crates (api, application, host-integration, hooks, policy, private-fs, rusqlite-runtime, store, temporal-query, tool-catalog) and the V2 domain contracts, with protobuf node kinds now unconditional graph vocabulary. Hook spool roots are refused unless private to the current owner (and gain a private ACL on Windows), and Windows lock contention in the hook admission ledger and storage sidecar locks is typed as busy/contended instead of surfacing as I/O errors.

.claude/skills/automation-run-review/.tracedecay-materialization.json

@@ -1,8 +1,8 @@
 {
   "files": {
-    "SKILL.md": "sha256:ce428b37c4067c28a8bfa803e31e5647f023aa6996be5997e065b6e9d75c1ebb"
+    "SKILL.md": "sha256:72250a902f26620d2bb6c5aea1a1ae198aba382f061ae365d58cea71416d3d78"
   },
   "managed_by": "tracedecay-automation",
-  "package_hash": "sha256:070f5045d0af6f415c30166b75ecc0b3f4b2c9aaf61a23eaf8bb42a6900a390e",
+  "package_hash": "sha256:62c256a24e756b8b9270ed092477e24daa7d80aa721328de3d7749b8c232aa9d",
   "skill_id": "automation-run-review"
 }

.claude/skills/automation-run-review/SKILL.md

@@ -1,10 +1,25 @@
 ---
 name: automation-run-review
-description: "Use when Review self-improvement automation runs and activation policy."
+description: "Use when reviewing self-improvement automation run status, validation evidence, automatic skill activation, or memory-curation outcomes."
 managed-by: tracedecay-automation
 skill-id: "automation-run-review"
-content-hash: sha256:070f5045d0af6f415c30166b75ecc0b3f4b2c9aaf61a23eaf8bb42a6900a390e
+content-hash: sha256:62c256a24e756b8b9270ed092477e24daa7d80aa721328de3d7749b8c232aa9d
 skill-version: 1783629450
 ---
 
-Check the run ledger, activation policy, and approval state before applying changes.
+# Automation run review
+
+Review automation without mutating it:
+
+1. Use `tracedecay_automation_run_list` to find the exact run id.
+2. Use `tracedecay_automation_run_view` to inspect terminal status, counts,
+   validation report, effects, and advertised artifact kinds.
+3. Use `tracedecay_automation_run_artifact_view` only for an artifact kind
+   advertised by that run; verify the returned hash-backed payload against the
+   terminal record.
+4. For skill-writer runs, verify automatic validation, activation, and
+   materialization against `tracedecay_skill_list` and
+   `tracedecay_skill_view`. For memory-curator runs, verify committed effects
+   with read-only fact queries.
+5. Report failures after committed effects as reconciliation work. Never rerun
+   blindly or manufacture a manual settlement step.

.claude/skills/evaluating-hook-hints/SKILL.md

@@ -1,32 +1,36 @@
 ---
 name: evaluating-hook-hints
-description: "TraceDecay Dev: Use when auditing, testing, debugging, or improving TraceDecay hook hint behavior, especially Codex/Claude/Cursor hint injection, verbosity, repetition, dedupe, token efficiency, real transcript examples, synthetic scenarios, or `src/hooks/tool_hints*` changes."
+description: "Evaluate TraceDecay hook hint relevance, repetition, and host-visible output when auditing or changing hint behavior."
 ---
 
-# TraceDecay Dev: Evaluating Hook Hints
-
-Use this skill for TraceDecay repo development only. These are repo-local dev instructions (`.claude/skills` / `.codex/skills`), not plugin-distributed skills.
-
-## Workflow
-
-1. Start with TraceDecay context for `src/hooks/tool_hints.rs`, `src/hooks/tool_hints/classifiers.rs`, `src/hooks/tool_hints/evals.rs`, host adapters in `src/hooks/{codex,claude,cursor}.rs`, and recent transcript evidence.
-2. Render model-visible hook input when judging verbosity:
-   `scripts/render-codex-hook-inputs.py --glob '/home/zack/.codex/sessions/**/*.jsonl' --all --limit 5 --max-chars 800`.
-3. Run deterministic evals before behavior edits:
-   `cargo test --lib hooks::tool_hints::evals -- --nocapture`.
-4. Score hints on four axes: relevance, silence when no hint is needed, compactness, and rotation/dedupe after the model has seen a category.
-5. Prefer tightening classifiers, budgets, or dedupe over adding broad static instructions. Use bundled skills and tool discovery as the durable guidance layer.
-6. After edits, run focused host tests for the touched adapter:
-   `cargo test --lib hooks::tool_hints:: hooks::codex::tests::` for Codex prompt hints, or the matching Claude/Cursor hook tests.
-
-## Acceptance Rules
-
-- Hints should be contextual and short; avoid generic TraceDecay availability boilerplate.
-- Real-world transcript cases and synthetic cases should both be represented in `src/hooks/tool_hints/evals.rs`.
-- A normal user prompt should not be wrapped into a noisy `UserPromptSubmit hook (completed)` model-visible user message.
-- No hint is a valid outcome when the request does not need TraceDecay guidance.
-- Repeated native behavior should get at most one initial hint plus one later escalation per category, bounded by the session budget.
-
-## References
-
-Read `references/hint-eval-signals.md` when deciding whether a scenario belongs in evals or in an adapter-specific integration test.
+# Evaluating Hook Hints
+
+Inspect the hint classifier, dedupe state, affected host adapters, and relevant
+transcript evidence before changing behavior. Current sources live under
+`crates/tracedecay-agent-hosts/src/hooks/`; locate the current modules rather
+than relying on historical root `src/hooks/` paths.
+
+For transcript regressions, render the selected session with
+`scripts/render-codex-hook-inputs.py /path/to/rollout.jsonl --all --limit 5`.
+Choose the user's relevant sessions; do not scan a fixed operator home by default.
+
+Judge relevance, appropriate silence, compactness, and dedupe after a category
+has already been shown. Prefer tightening the responsible classifier or dedupe
+behavior over broad static instructions. Normal prompts should not acquire
+noisy hook-completion wrappers; no hint is a valid outcome.
+
+For behavior changes, use real and synthetic cases that exercise the changed
+failure and neighboring cases that should remain silent. Read
+[hint-eval-signals.md](references/hint-eval-signals.md) to choose classifier
+evals versus adapter tests. A review-only pass does not require running builds.
+
+Run relevant existing evals in the owning package:
+`cargo test -p tracedecay-agent-hosts --lib hooks::tool_hints::evals -- --nocapture`.
+For an adapter change, run its focused tests separately; Cargo accepts one name
+filter per invocation. Confirm non-zero test counts. Audit all supported hosts
+when shared hook behavior changes; test affected behavior without repeating
+identical substrate cases across every host.
+
+Preserve contextual hint budgets and the current bounded repetition policy;
+do not weaken limits to hide excessive hints. Report observed behavior,
+changes or findings, and the relevant verification.

.claude/skills/inspecting-automation-cycles/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: inspecting-automation-cycles
-description: 'TraceDecay Dev: Use when auditing TraceDecay automation loops, skipped runs, memory-curator/session-reflector/skill-writer output, apply policy, or run artifacts.'
+description: "Inspect TraceDecay automation run outcomes, suspicious skips, and curator or skill-writer validation receipts."
 ---
 
 # TraceDecay Dev: Inspecting Automation Cycles
@@ -11,17 +11,32 @@ analytics prove whether generated output was adopted.
 
 ## Workflow
 
-1. Start with `tracedecay automation config get` to identify enabled tasks,
-   schedules, locks, profile paths, and apply policy.
-2. List recent runs with `tracedecay automation runs list --limit 100`; group
-   by task and status before opening individual artifacts.
-3. For failures or suspicious skips, open the relevant artifact with
-   `tracedecay_automation_run_artifact_view` or
-   `tracedecay tool automation_run_artifact_view --args ...`.
-4. Inspect model-managed memory outcomes plus configured managed-skill review
-   queues: `tracedecay automation facts list`, dashboard telemetry, and
-   `tracedecay_skill_list --state pending`.
-5. Check adoption evidence: `tracedecay analytics diagnostics --all --no-sync`,
+1. Start from the exact run if known. For scheduling or loop-health questions,
+   use `tracedecay automation config get` to inspect enabled tasks, schedules,
+   locks, and profile paths.
+2. When the operator requests an immediate memory-curation cycle, use the sole
+   public semantic launcher, `fact_store_curate`, through its MCP adapter
+   `tracedecay_fact_store_curate`, generic CLI adapter `tracedecay tool
+   fact_store_curate`, or HTTP adapter `POST
+   /api/application/retained/fact_store_curate`. Its request accepts only the
+   optional `fact_review_limit` and `min_confidence_millionths` bounds. Each
+   adapter invokes the same daemon-owned operation; the daemon derives run
+   identity, task selection, operations, validation, policy, and effect
+   settlement.
+3. When locating runs or reviewing aggregate health, use
+   `tracedecay automation runs list --limit 100`; bound the review window and
+   group by task/status before opening suspicious artifacts.
+4. Inspect one exact run with `tracedecay automation runs view <run_id>`.
+   Read its verified artifacts with
+   `tracedecay automation runs artifact <run_id> <kind> --json`,
+   `GET /api/automation/runs/<run_id>/artifacts/<kind>`, or the read-only MCP
+   tool `tracedecay_automation_run_artifact_view`. MCP automation analytics
+   summarizes run history; exact MCP run list/view is not currently exposed.
+5. For memory or skill outcomes, inspect the relevant terminal state with
+   `tracedecay automation facts list`, dashboard telemetry, and
+   `tracedecay_skill_list --state active`.
+6. When adoption is in scope, use `tracedecay analytics diagnostics --no-sync`
+   (add `--all` only for a cross-project question),
    `tracedecay sessions search "mcp__tracedecay" --provider all`, and managed
    skill usage counts.
 
@@ -32,15 +47,16 @@ analytics prove whether generated output was adopted.
 | `scheduler_interval_not_elapsed` | Healthy throttling | Count only, do not fix. |
 | `scheduler_lock_active` | Another run owns the loop | Check age before calling stale. |
 | `no_new_session_activity` | Nothing new to process | Verify transcript ingest if surprising. |
-| `validation_gate` artifact | Mutation passed validation | Inspect apply-policy state or dashboard artifact. |
-| Many fact proposal records | Inspect validation/apply telemetry | Use `tracedecay:project-memory`. |
-| Active managed skills with zero use | Adoption telemetry gap | Use `tracedecay:diagnosing-analytics`. |
+| `validation_gate` artifact | Mutation passed validation | Inspect terminal automatic application/deployment receipts. |
+| Many automatic fact receipts | Inspect applied/quarantined outcomes and telemetry | Use `tracedecay automation facts list`. |
+| Active managed skills with zero use | Possible lack of opportunity or telemetry coverage | Confirm a missed relevant task before diagnosing adoption. |
 
 ## Guardrails
 
-- Prefer read-only inspection. Do not mutate fact records.
-- Do not approve, reject, delete, or apply managed-skill drafts unless the user
-  explicitly asked for mutation.
+- After any requested run, keep inspection read-only. Do not submit curator
+  operations or approve, reject, or apply its output.
+- Validated memory-curator and skill-writer output settles automatically;
+  inspect receipts rather than waiting for a manual gate.
 - Do not treat skipped runs as failures until grouped by skip reason and age.
 - Avoid parallel `tracedecay_skill_view` calls against one profile while
   automation may write usage ledgers. If a usage read reports a truncated JSON
@@ -50,6 +66,6 @@ analytics prove whether generated output was adopted.
 
 ## Deliverable
 
-Report task/status counts, the exact run or artifact ids inspected, apply-policy
-state, adoption gaps, and the next concrete command for any mutation the user
-should choose.
+Report the inspected run/artifact ids, relevant terminal outcomes, evidence,
+and limitations. Include launcher details, aggregate counts, or adoption findings
+only when those were part of the task; a read-only review needs no new run.