feat: logs chain support in logstore (backend)

.claude/skills/investigate-issue/SKILL.md

@@ -14,10 +14,17 @@ Fetch a GitHub issue, analyze the report, search the codebase for relevant code,
 3. Codebase Analysis + Documentation Research (from Step 3, including sub-step 3e)
 4. Impact Analysis (from Step 4)
 5. Test Plan (from Step 5)
-6. Full Presentation (Step 6 template)
+6. Regression Rerun Scope (from Step 5e) -- which existing tests must rerun, and why
+7. TDD: Failing Tests (from Step 5f) -- Bug issues only: the test source AND the actual
+   red output from the applicable Makefile recipe, pasted verbatim, BEFORE asking to
+   implement
+8. Full Presentation (Step 6 template)
 
 If any section is missing, go back and complete it before presenting the report.
 
+For Bug issues the approval gate is NOT "may I write a test?" -- the failing test is already
+written and shown to be red. The gate is "may I write the fix?"
+
 ## Usage
 
 ```
@@ -32,8 +39,13 @@ If any section is missing, go back and complete it before presenting the report.
 3. **Search the codebase and research docs** -- Find relevant code, then research the libraries it depends on via Context7 and WebSearch
 4. **Analyze impact** -- Cross-reference codebase findings with documentation to identify side effects, dependencies, and breaking changes
 5. **Suggest tests** -- If changes touch `core/`, recommend specific LLM and MCP test additions
-6. **Present the plan** -- Show findings and recommended changes to the user
-7. **Implement with approval** -- After plan approval, make changes one at a time with user confirmation
+5b. **Scope the reruns** -- Use coverage to determine which existing tests exercise the lines
+    you plan to change, and tier them by necessity
+5c. **Go red (Bug issues)** -- Write the regression test(s) and run them to confirm failure for
+    the right reason, BEFORE presenting the plan
+6. **Present the plan** -- Show findings, the red test output, the rerun scope, and the
+   recommended fix
+7. **Implement with approval** -- After approval, apply the fix and show red-to-green
 
 ## Step 1: Fetch the Issue
 
@@ -410,6 +422,127 @@ If UI changes are involved, recommend E2E test updates following the patterns in
 make run-e2e FLOW=<feature>
 ```
 
+### 5e. Determine Rerun Scope from Coverage
+
+Do not guess which tests are affected -- measure it. Package-level coverage is too coarse:
+it proves the package is tested, not that any test executes the specific lines you are
+changing. Attribute coverage per test.
+
+**Step 1 -- Establish the changed-line set.** For each file in the Implementation Plan, list
+the functions/methods you will modify AND the line ranges within them. Step 3 filters the
+coverage profile by line range, so symbol names alone are not enough.
+
+**Step 2 -- Find candidate tests.** Every test in the changed file's package, plus every test
+in the packages of its callers (from the Step 4b `grep` for callers):
+
+Enumerate by PACKAGE, not by file or by symbol name. All `_test.go` files in a directory
+compile into one test binary, and many tests reach the target through helpers or fixtures
+rather than naming it -- so a textual grep for `<TargetSymbol>` under-reports badly (in
+`core/mcp`, 60 test functions exist but only one file names `MCPManager`).
+
+```bash
+# 1. Changed file's own package -- every test file, not just the matching one
+grep -hn "^func Test" <pkg>/*_test.go
+
+# 2. Caller packages -- map Step 4b's caller hits to directories, then enumerate each
+grep -rl "<TargetSymbol>" --include='*.go' core/ framework/ transports/ plugins/ \
+  | xargs -n1 dirname | sort -u \
+  | while read -r d; do grep -Hn "^func Test" "$d"/*_test.go 2>/dev/null; done
+```
+
+Over-inclusion is fine here -- Step 3 narrows the list by measurement. Omission is not:
+a dropped candidate never gets coverage-checked and silently disappears from the report.
+
+**Step 3 -- Attribute coverage per test.** Run each candidate with its OWN profile and check
+whether it actually reaches the target symbol. A profile from the whole package cannot tell
+you this.
+
+Coverage attribution is the ONE place raw `go test` is allowed: no Makefile recipe accepts
+`-coverprofile`. This profile is a measurement tool only -- it is never the red/green
+evidence in the report. Red and green validation always runs through the Make target
+(Step 5f).
+
+```bash
+cd <module>
+# -coverpkg is REQUIRED: by default a test only instruments its OWN package, so a
+# caller-package test would show zero blocks for the target and be wrongly dropped.
+go test ./<candidate-pkg>/... -run '^<TestName>$' -covermode=count \
+  -coverpkg=./... -coverprofile=<scratchpad>/cover-<TestName>.out
+
+# Filter the raw profile to the changed line range. Do NOT use `go tool cover -func`:
+# it reports a per-FUNCTION percentage, so a test covering another branch of the same
+# function reads as "covered" while your changed line has count=0.
+awk -v file="<changed-file>" -v lo=<startLine> -v hi=<endLine> 'NR>1 {
+  split($1, a, ":"); split(a[2], r, ","); split(r[1], s, "."); split(r[2], e, ".");
+  if (a[1] ~ file && s[1] <= hi && e[1] >= lo)
+    printf "  lines %s-%s  count=%s\n", s[1], e[1], $3
+}' <scratchpad>/cover-<TestName>.out
+```
+
+Profile line grammar: `<import-path>/file.go:startLine.startCol,endLine.endCol numStmt count`.
+Pass `<changed-file>` to `file` exactly as it appears in the diff, with no extra extension:
+`~` is a regex match against that import-path-qualified field, so a repo-relative path such as
+`bifrost-http/lib/streamreader.go` is the right granularity. A bare `streamreader.go` would
+also match a same-named file in any other package `-coverpkg=./...` pulled in, and a doubled
+extension (`streamreader.go.go`) matches nothing -- which is indistinguishable from "no test
+covers this change" and silently drops every required rerun. The last
+field is the execution count. A non-zero count on ANY block overlapping your changed range
+means that test executes the code you are changing -- it is a required rerun. All-zero (or
+no overlapping block) means it does not.
+
+For UI changes, use the framework's own dependency graph instead of Go coverage:
+```bash
+cd ui && ./node_modules/.bin/vitest related <changed-file> --run
+```
+Use the lockfile-pinned binary, not `npx vitest`: with a non-TTY stdin (which is every agent
+run) npm assumes `--yes` and silently installs whatever version the registry currently calls
+latest when `ui/node_modules` is missing, bypassing `ui/package-lock.json`.
+
+**Step 4 -- Tier the results.** Report reruns in three tiers so the user can see what is
+mandatory versus precautionary:
+
+| Tier | Definition | Obligation |
+|------|-----------|------------|
+| **Tier 1 -- Must rerun** | Coverage shows the test executes a changed line | Blocking. A failure here is caused by your change |
+| **Tier 2 -- Should rerun** | Same package, or asserts a contract your change touches, but does not cover the changed line | Run before handing off. Cheap and catches contract drift |
+| **Tier 3 -- Downstream** | Tests in packages of callers/dependents identified in Step 4b | Run if Tier 1 or 2 revealed anything, or if the change altered an exported signature or shared invariant |
+
+Explicitly list any test you are NOT rerunning and why (e.g. requires live provider
+credentials, unrelated subsystem). Silent omission reads as "everything passed."
+
+Note that provider-gated suites (`make test-core PROVIDER=...`) hit live APIs. If a Tier 1
+test is provider-gated, say so -- the user decides whether to spend the call.
+
+### 5f. Write and Run the Failing Tests -- Red (Bug issues only)
+
+For issues classified **Bug** in Step 2a, write the regression test(s) and confirm red
+*before* presenting the plan. This is a change from asking permission first: a plan whose
+test has not been run is a hypothesis, and reviewers cannot distinguish a real reproduction
+from a plausible one.
+
+1. Write the test(s) from the Step 5 Test Plan, targeting the actual root cause from Step 3/4.
+   Write them against the CURRENT code -- do not write the fix.
+2. Run them with the correct Makefile recipe (never raw `go test` for suites that have one).
+3. Confirm the failure is for the **expected reason**: the missing behavior, wrong bytes, or
+   absent field. A compile error, typo, nil panic, or unrelated assertion is NOT a valid red
+   -- fix the test and rerun until the failure is the real defect.
+4. Capture the verbatim failure output. Do not paraphrase or summarize it.
+5. **Redact before it leaves the scratchpad.** Provider-gated suites hit live APIs with real
+   credentials (`OPENAI_API_KEY`, `AWS_SECRET_ACCESS_KEY`, and ~20 others), and upstream
+   401/403 bodies echoed through `bifrostErr.Error.Message` can carry the key or auth header.
+   Keep the raw output in `<scratchpad>/` -- never commit it, never paste it. Produce a
+   redacted transcript for the report, replacing each secret with `[REDACTED: <what>]` so the
+   removal is visible. Redaction is narrow: it MUST preserve the command, the failing
+   assertion with actual-vs-expected values, and the stack trace. If redacting would remove
+   the evidence itself, say so rather than trimming the assertion.
+
+If the test unexpectedly PASSES, stop. The diagnosis in Step 3/4 is wrong or incomplete.
+Return to Step 3 and say so plainly in the report rather than adjusting the test until it
+fails.
+
+Creating test files is the one write action permitted before plan approval, because the test
+is itself the evidence. Do not touch any non-test source file at this stage.
+
 ## Step 6: Present Findings
 
 Present everything to the user in this structured format:
@@ -485,6 +618,41 @@ Copy the research table from Step 3e here. If you skipped Step 3e, go back and d
 |------|------|---------------|
 | `TestNewScenario` | `<path>` | <scenario description> |
 
+### TDD: Failing Tests (Red)
+
+<Bug issues only. If the issue is a Feature or Docs, write "N/A -- <type> issue, red-before-green
+does not apply per AGENTS.md" and omit the rest of this section.>
+
+#### Test Source
+<The full source of each new/extended test, as written. Not a description -- the actual code.>
+
+#### Red Output (verbatim, redacted)
+```
+<paste the failing test output, including the command that produced it. Secrets replaced
+with [REDACTED: <what>] -- nothing else altered. Raw output stays in <scratchpad>/.>
+```
+
+#### Why This Failure Is the Real Defect
+<Explain how the assertion that failed maps to the root cause in the Codebase Analysis. State
+explicitly that this is not a compile error, typo, or unrelated panic.>
+
+### Regression Rerun Scope
+
+<From Step 5e. Coverage-attributed, not guessed.>
+
+| Tier | Test | File | Covers Changed Line? | Why It Reruns |
+|------|------|------|---------------------|---------------|
+| 1 | `TestX` | `<path>` | Yes -- `<symbol>` count N | <what it guards> |
+| 2 | `TestY` | `<path>` | No -- same package | <contract it asserts> |
+| 3 | `TestZ` | `<path>` | No -- caller package | <downstream invariant> |
+
+**Rerun commands:**
+```bash
+<exact commands, tier by tier>
+```
+
+**Not rerunning:** <list with reasons, or "None -- full scope covered above">
+
 <If changes touch core/>
 #### LLM Test Additions
 <Specific LLM test recommendations per Section 5b format>
@@ -504,25 +672,57 @@ Copy the research table from Step 3e here. If you skipped Step 3e, go back and d
 
 ---
 
-**Proceed with implementation?** (yes / no / modify plan)
+<If Bug>
+The failing test above is committed to disk and confirmed red. No source file has been
+modified.
+</If>
+<If Feature or Docs>
+No source file has been modified. Red-before-green does not apply to <type> issues per
+AGENTS.md; tests are written alongside the implementation in Step 7.
+</If>
+
+**Implement the fix now?** (yes / no / modify plan)
 ```
 
 ## Step 7: Implement with Per-Change Approval
 
 Once the user approves the plan:
 
-### 7a. Create a Todo List
+### 7a. Bug issues: the red already happened (per AGENTS.md "Testing" section)
+
+For **Bug** issues the failing test was written and confirmed red in Step 5f, before the
+approval gate. Step 7 therefore starts at the fix, not the test:
+
+1. Apply the fix changes from the plan (Step 7c below).
+2. Re-run the exact same command from the Step 6 "Red Output" block and confirm it now passes.
+3. Present red-then-green as a pair: the command, the prior failure, the new pass.
+4. Run the Tier 1 and Tier 2 reruns from the Regression Rerun Scope. Report every result,
+   including any pre-existing failure unrelated to this change -- say so explicitly rather
+   than omitting it.
+
+Do not modify the test while implementing the fix. If the test needs to change to pass, the
+diagnosis was wrong: stop and tell the user rather than editing the test to match the code.
+
+This does not apply to Feature or Docs issues -- AGENTS.md scopes "red before green" to bug
+fixes. For those, tests are added per the Test Plan after the implementation, and Step 5f is
+skipped.
+
+### 7b. Create a Todo List
 
-Create a todo item for each change in the plan:
+Create a todo item for each change in the plan. For Bug issues the regression test already
+exists and was confirmed red in Step 5f, before the approval gate -- so it enters the list
+already completed and the first pending task is the fix. Do not re-write or modify it (see 7a):
 ```
-1. Change 1: <description> -- pending
-2. Change 2: <description> -- pending
-3. Update test: <description> -- pending
-4. Add new test: <description> -- pending
+1. Write failing test: <description> -- completed    (Bug issues only; confirmed red in Step 5f)
+2. Change 1: <description> -- pending
+3. Change 2: <description> -- pending
+4. Update existing test: <description> -- pending
 5. Verify all tests pass -- pending
 ```
+For Feature and Docs issues, omit item 1 entirely: Step 5f is skipped for those, and the new
+tests from the Test Plan are added after the implementation, as their own pending items.
 
-### 7b. For Each Change
+### 7c. For Each Change
 
 Before making any edit, present the change to the user:
 
@@ -542,7 +742,7 @@ Before making any edit, present the change to the user:
 
 Wait for user approval before applying. If user says "no", skip and move to the next change. If user says "modify", discuss and adjust.
 
-### 7c. After All Changes
+### 7d. After All Changes
 
 Once all approved changes are applied:
 
@@ -561,7 +761,7 @@ Once all approved changes are applied:
    make run-e2e FLOW=<feature>
    ```
 
-2. Report results to the user
+2. Report results to the user, including the red-then-green transcript/summary for Bug issues (what failed before, what passes now)
 3. If tests fail, investigate and propose fixes (with approval)
 
 ## Error Handling