@engramlabs/mcp 0.1.2-alpha → 0.1.3-alpha

package/skills/engram-index/references/memorization-catalog.md

@@ -0,0 +1,81 @@
+# Memorization catalog — what engram-index writes, exactly
+
+The reference for phase 2 (memorize) of engram-index. One concern per
+memory; every claim labeled; every procedure seen working.
+
+## Memory formats (write_memory)
+
+### Stack + layout
+```
+write_memory({ "content": "[proven] Rust workspace, 30+ crates; core/
+  adapters/backends split enforced by scripts/ci/check-engine-neutrality.sh
+  — evidence: architecture tool showed core crates; CI script read via
+  fetch_content" })
+```
+
+### Invariants (the rules this repo lives by)
+```
+write_memory({ "content": "[proven] engram-domain must not depend on SQL,
+  vector stores, or async runtimes — evidence: check-engine-neutrality.sh
+  gates CI; violation names engine types in core crates" })
+```
+Label `[likely]` when inferred from structure alone ("naming suggests
+layering" is not proof); upgrade to `[proven]` only when a check, test,
+or doc enforces it.
+
+### Sharp edges (what bites)
+```
+write_memory({ "content": "[proven] bridge symbol: resolve_symbol in
+  core/code — 14 dependents across 5 crates; change_impact shows ripple
+  into scanner, mcp tools, and tests. Touch last, test wide." })
+```
+Sources of sharp edges: `architecture` bridge list, `change_impact`
+output on symbols you expect to touch, temporal traps from
+`whats_changed`.
+
+### Core abstractions (the "understand this = understand the system" set)
+```
+write_memory({ "content": "[proven] MemoryService trait is the central
+  abstraction (top PageRank) — every write path flows through it;
+  adapters implement, orchestration composes. evidence: architecture
+  tool, symbol_context depth 2" })
+```
+
+## Procedure formats (procedure_put)
+
+Only procedures whose steps were SEEN working (CI configs, READMEs,
+this session). Untested steps must say so in `trigger`.
+
+```
+procedure_put({ "name": "verify",
+  "trigger": "before handoff",
+  "steps": ["cargo fmt --all", "cargo check --workspace",
+            "pnpm run typecheck", "pnpm run test",
+            "scripts/ci/check-contracts.sh"] })
+
+procedure_put({ "name": "scan-repo",
+  "trigger": "index refresh",
+  "steps": ["scan_repo {path: <repo>}", "architecture {limit: 20}",
+            "graph_health {}"] })
+```
+
+## Entity/relationship formats (put_entity / put_relationship)
+
+Top abstractions only — the graph already knows every symbol; entities
+are for the CONCEPTS the graph can't infer:
+
+```
+put_entity({ "name": "Engine Neutrality", "kind": "concept" })
+put_relationship({ "subject": "Engine Neutrality", "predicate":
+  "realized_by", "object": "check-engine-neutrality" })
+```
+
+Bridge concepts to the code that realizes them; a concept linked to
+nothing is an orphan in a disconnected subgraph.
+
+## What NOT to memorize
+
+- File counts, line counts, dependency version trivia
+- Boilerplate names, test fixture names
+- Anything `architecture`/`symbol_context` answers on demand
+- Session play-by-play (that's engram-learn's job, and only the durable parts)

package/skills/engram-index/references/rea-process.md

@@ -0,0 +1,79 @@
+# REA process for code indexing
+
+The evidence-first discipline (adapted from the REA — Reverse Engineer
+Anything — method) applied to understanding and memorizing a codebase.
+
+## The process, stage by stage
+
+### 1. Target scoping
+Define what is being understood before touching anything:
+- What kind of system is this? (service, library, app, agent tool)
+- What will "understood" mean here? (can answer where/how questions,
+  can plan changes safely, can recall invariants)
+- What is already known? (check staleness — if a fresh index exists,
+  only delta-memorize)
+
+**Stop condition:** scope stated in one sentence before any tool call.
+
+### 2. Surface mapping
+Map the terrain without reading files:
+- `scan_repo` — the structural pass (symbols, edges, communities)
+- `architecture {limit: 20}` — central symbols, bridges, stats
+- `graph_health` — is the graph trustworthy?
+
+Surface mapping answers: how big, how coupled, where does complexity
+live? It does NOT answer how anything works — that's tracing.
+
+### 3. Feature tracing
+Follow one behavior from trigger to outcome through the graph:
+- Start from the entry point (top central symbol, or a named feature)
+- `symbol_context` each hop: callers, callees, community
+- `change_impact` on bridges to understand blast radius
+- `fetch_content` the load-bearing files to verify the graph's story
+
+Record every hop: file, symbol, what the edge means. A trace that
+skips a hop is a guess, not a trace.
+
+### 4. Evidence collection
+Every claim gets its evidence AT COLLECTION TIME, not later:
+
+| Label | Meaning | Evidence standard |
+|---|---|---|
+| `[proven]` | Verified against source or graph | tool + query + what it showed |
+| `[likely]` | Strong signal, unverified | naming, structure, docs memory |
+| `[guessed]` | Hypothesis only | must say so explicitly |
+
+Rules:
+- Never claim how something works without graph/source evidence.
+- Separate facts from interpretation — the label IS the separation.
+- Start with the simplest trace that proves the behavior.
+- Pseudocode-level summaries of files you haven't fetched are `[likely]`
+  at best.
+
+### 5. Reconstruction (memorization)
+Turn findings into durable memory — one concern per memory, written so a
+future agent in a fresh session can act on it:
+- Stack + layout invariants
+- Sharp edges (bridges, god modules, temporal traps)
+- Core abstractions (top PageRank, one line each)
+- Build/test/verify procedures (exact commands, only ones seen working)
+
+An unmemorized finding is a finding you'll pay for twice.
+
+### 6. Verification (write → read-back)
+- Recall 3 probe queries a future agent would actually ask.
+- A probe that fails = a memory written badly = rewrite it.
+- **An index that cannot be recalled is not an index.**
+
+### 7. Final report
+- N symbols, M modules, core abstractions, bridges to respect
+- What was memorized + confidence split (proven/likely/guessed counts)
+- Unknowns worth investigating — honesty about holes
+
+## The final check (run before claiming done)
+
+- What am I missing in the overview?
+- Is each claim proven or just plausible?
+- Did I mistake graph structure for verified behavior?
+- Would these memories survive the next refactor?
+- What evidence would change my mind?

package/skills/engram-learn/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: engram-learn
+description: Distill durable learnings from a session, doc, or fix into engram — decisions with rationale, gotchas and resolutions, validated procedures, source-grounded facts, belief updates. Trigger on "remember this", "learn from this session", after a meaningful bug fix, or at the end of a substantive work session.
+---
+
+# engram-learn
+
+Turn what just happened into durable memory. The agent does the extraction
+and judgment; engram stores and recalls. Learners capture **decisions,
+gotchas, and procedures** — not transcripts.
+
+## Contract
+
+1. No trivia: if a future agent wouldn't act on it, don't write it.
+2. No duplicates: recall first; update or skip if it's already known.
+3. Decisions record the *why*, not just the *what*.
+4. Source-grounded facts cite their source (`store_knowledge`, not `write_memory`).
+
+## Workflow
+
+### 1. What kind of learning is this?
+
+| Kind | Tool | Shape |
+|---|---|---|
+| Decision + rationale | `write_memory` | "Decided X over Y because Z" |
+| Gotcha / resolution | `write_memory` | "X bites when Y; fix: Z" |
+| Validated procedure | `procedure_put` | exact steps that worked |
+| Fact from a source | `store_knowledge` | entities/facts with the doc path |
+| Changed stance | `belief_get` → update or let contradiction stand | subject + new position |
+| Replayable doc | `index_docs` | verbatim, chunked for recall |
+
+### 2. Recall before writing (dedup)
+
+```
+recall({ "query": "<the learning's key terms>" })
+```
+
+If it's already there: skip (nothing new), or write only the delta
+("update: also fails on Windows"), or bump the procedure's accuracy by
+re-putting it.
+
+### 3. Write
+
+```
+write_memory({ "content": "Decided to gate npm publish on the scan gate: a package is the most-attacked surface (lesson: OpenClaw). Context: RFC-0021." })
+```
+
+```
+procedure_put({ "name": "re-tag-release", "trigger": "publish retry",
+  "steps": ["gh release delete vX --yes", "git tag -d vX",
+            "git push origin :refs/tags/vX", "git tag vX", "git push origin vX"] })
+```
+
+For stance changes, check the belief state first:
+
+```
+belief_get({ "subject": "engram-index auto-triggers" })
+```
+
+If a belief contradicts the new learning, let the contradiction stand —
+`contradiction_list` will surface the tension later. Never silently
+overwrite a belief with history behind it.
+
+For source material (RFCs, ADRs, design docs) the project should recall:
+
+```
+store_knowledge({ "entities": [], "facts": [], "relationships": [], "idempotency_key": "<doc-id>" })
+```
+
+Bridge concepts to code where you can — a concept not linked to what
+realizes it is an orphan. Use `search({ "query": "<term>" })` to find
+real symbol names before linking.
+
+### 4. Confirm
+
+One read-back per critical write:
+
+```
+recall({ "query": "<the decision's core terms>" })
+```
+
+## When it fails
+
+- `write_memory` errors → report; never retry in a loop.
+- Nothing worth learning → say "nothing durable here" and stop. Silence
+  is a valid outcome; forced learnings are noise.
+
+## Anti-patterns
+
+- Session-transcript dumps ("we ran tests, then edited X, then…").
+- Duplicating what `recall` already returns.
+- Unvalidated procedures (steps never executed).
+- Belief overwrites that erase history.
+
+## Final check
+
+- Would a future agent in a fresh session act differently because of these writes?
+- Every decision has its why?
+- Procedures were actually run?

package/skills/engram-plan/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: engram-plan
+description: Plan a change by mining the engram index first — past issues, patterns, invariants, blast radius — using the right workflow for the job. Triage (classify + route), Bugfix (root cause + regression guard), or Story/Feature (precedents + per-layer steps). Trigger when asked to solve/plan/triage/implement anything non-trivial, before editing.
+---
+
+# engram-plan
+
+Plan from evidence, not vibes. The index already knows this repo's
+structure, invariants, history, and past failures — mine it before
+writing a line of the plan.
+
+**Pick the workflow first** — they are different disciplines:
+
+| The request smells like… | Workflow | Reference |
+|---|---|---|
+| "this is broken", unclear severity, red CI | **Triage** — classify + route, don't fix | `references/plan-triage.md` |
+| Reproduced failure, regression, crash | **Bugfix** — root cause + regression guard | `references/plan-bugfix.md` |
+| New capability, story, integration | **Story/Feature** — precedents + per-layer steps | `references/plan-story.md` |
+
+All three share the moves below; the references carry each one's
+specific discipline.
+
+## Contract
+
+1. Mine before writing: past work, past failures, invariants, blast radius, tensions.
+2. **Every plan starts with a past-pattern search** — a fix/feature that ignores how this repo solved it before is planning amnesia.
+3. Findings are evidence-labeled; risks are quantified from the graph.
+4. Every step is independently verifiable — it names the command that proves it.
+5. The plan is written to memory so `engram-implement` can recall it; recurring shapes become procedures.
+
+## Workflow (shared moves)
+
+### 1. Frame the change
+
+One paragraph: what changes, for whom, what "done" means. Ambiguity →
+list your interpretation in Open Questions; don't silently pick.
+
+### 2. Search the past (engram-search discipline)
+
+```
+recall({ "query": "<domain terms> fix design decisions" })
+search({ "query": "<likely touchpoint symbols>" })
+procedure_list({})
+contradiction_list({})
+```
+
+Mine for: past fixes with the same symptom · precedents for the same
+feature shape · indexed invariants the change must respect · existing
+runbooks (if one covers this, following it beats planning) · open
+tensions. **Record the search result either way** — "no past
+occurrences" is a finding.
+
+### 3. Map the surface
+
+```
+architecture({ "limit": 15 })
+symbol_context({ "symbol": "<touchpoint>", "depth": 2 })
+change_impact({ "target": "<touchpoint>" })
+```
+
+Blast radius per touchpoint → Risks. Crossed layers → explicit
+per-layer steps.
+
+### 4. Write the plan (fixed sections)
+
+**Overview** (the repo's vocabulary) · **Findings** (labeled, including
+the past-pattern search result) · **Risks** (blast radius + invariants
+threatened + mitigations) · **Steps** (ordered, each with its verify
+command) · **Open Questions** (what the index could NOT answer).
+
+### 5. Persist plan + workflow
+
+```
+write_memory({ "content": "PLAN <slug>: <overview>. Precedents: <found|none>. Steps: <N>. Top risks: <top risks>." })
+```
+
+When this shape recurs, capture the workflow that worked:
+
+```
+procedure_put({ "name": "plan-<workflow-type>", "trigger": "<when this shape appears>", "steps": ["<the moves that worked, in order>"] })
+```
+
+## When it fails
+
+- No index (recall/search empty) → plan against `scan_repo` + reads,
+  findings marked `[guessed]` where the graph would have proven them.
+  Suggest engram-index.
+- A recalled past fix contradicts the request's assumptions → surface
+  it before planning; the past fix is evidence, not noise.
+
+## Anti-patterns
+
+- Skipping the past-pattern search (the #1 planning failure).
+- Triage that fixes, bugfix plans without a regression test, story
+  plans without a precedent search.
+- Steps with no verification command.
+- Risks without graph evidence ("might be tricky" is not a risk).
+- Planning past an open contradiction without flagging it.
+
+## Final check
+
+- Right workflow for the request?
+- Did the past-pattern search run, and is its result in Findings?
+- Could a fresh agent implement from Findings + Steps alone?

package/skills/engram-plan/references/plan-bugfix.md

@@ -0,0 +1,66 @@
+# Plan workflow: BUGFIX
+
+Root cause first, minimal fix second, regression guard always.
+
+## When this workflow
+- Reproduced failure, cause unknown or partially known
+- Regression (something that used to work)
+- Post-triage routing (fast lane if a past pattern was recalled)
+
+## Steps
+
+### 1. Search the past — every bugfix starts here
+```
+recall({ "query": "<symptom terms> fix root cause" })
+search({ "query": "<failing symbol}" })
+procedure_list({})
+```
+- A past fix for the same symptom = the pattern to check first
+  (was it fully fixed, or did the same class resurface elsewhere?)
+- An indexed sharp edge near the failure = prime suspect
+- **Record the search**: "no past occurrences found" is itself a
+  finding ([proven] by absence, worth saying)
+
+### 2. Localize with the graph
+```
+symbol_context({ "symbol": "<failing symbol>", "depth": 2 })
+change_impact({ "target": "<suspect symbol>" })
+```
+- The failing symbol's neighborhood = the suspect pool
+- `fetch_content` the load-bearing file(s) — never theorize about code
+  you haven't read this session
+- If recently-changed code is in the neighborhood:
+  `whats_changed {}` to see what moved lately
+
+### 3. Root cause (the plan's Findings section)
+State it as a testable claim: "X fails because Y, when Z."
+Label it. `[proven]` requires either a repro trace or source evidence.
+A root cause you can't state in one sentence isn't found yet.
+
+### 4. Minimal fix + regression guard (Steps section)
+- Smallest change that removes the cause (not the symptom)
+- A test that fails before the fix and passes after — the regression
+  guard is mandatory, not optional
+- Blast radius from step 2 becomes the Risks section
+
+### 5. Persist the pattern (procedures for recurring classes)
+If this is the second+ occurrence of a failure class:
+
+```
+procedure_put({ "name": "fix-<failure-class>",
+  "trigger": "<symptom signature>",
+  "steps": ["<localization step>", "<root-cause check>",
+            "<the fix>", "<the regression test>"] })
+```
+Next triage of this class should hit the runbook, not rediscover it.
+
+## Output (hand to engram-implement)
+- **Findings**: symptom, root cause [labeled], past-occurrence search result
+- **Risks**: blast radius, what the regression test must cover
+- **Steps**: fix + test + verify command (exact)
+
+## Stop conditions
+- Root cause unprovable after localization → plan the investigation
+  (instrument, log, bisect) — don't plan a fix on a guess.
+- Fix would touch a bridge symbol → plan-wide test pass is a step, not
+  an afterthought.

package/skills/engram-plan/references/plan-story.md

@@ -0,0 +1,84 @@
+# Plan workflow: STORY / FEATURE
+
+New capability work. The mine-first discipline matters most here:
+stories die from unknown unknowns, and the index is where the unknowns
+are already written down.
+
+## When this workflow
+- New feature, story, or capability request
+- Refactor with a goal (not a bug, not a rename)
+- Integration of a new component
+
+## Steps
+
+### 1. Search the past — patterns, precedents, near-misses
+```
+recall({ "query": "<feature domain terms> design decisions" })
+search({ "query": "<adjacent existing capability>" })
+procedure_list({})
+```
+Mine for:
+- **Precedents**: was a similar feature planned/built/abandoned
+  before? (abandoned plans + their reasons are gold)
+- **Invariants** the feature must respect (indexed `[proven]` rules)
+- **Adjacent patterns**: how does this repo solve analogous problems?
+  (find the closest existing feature and mirror its shape)
+- **Open tensions**: `contradiction_list({})` — building on top of an
+  unresolved contradiction is planning to fail
+
+### 2. Map the integration surface
+```
+architecture({ "limit": 15 })
+symbol_context({ "symbol": "<primary touchpoint>", "depth": 2 })
+change_impact({ "target": "<each touchpoint>" })
+```
+- Where does the feature ATTACH? (ports, facades, tool registries)
+- What must NOT move? (bridges, invariants)
+- Which layers does it cross? (crossing layers = the plan needs
+  explicit steps per layer, or it will stop at the first boundary)
+
+### 3. Design in the repo's shape
+One paragraph: the feature in this repo's own vocabulary, mirroring
+the closest existing pattern found in step 1. A design that invents a
+new shape when a proven one exists needs a stated reason (that's an
+Open Question, not a surprise).
+
+### 4. Steps with per-layer verification
+Each step lands ONE layer and names its verify command:
+```
+1. Domain types + contracts (core/<crate>)
+   Verify: cargo check -p engram-<crate> + check-contracts.sh
+2. Adapter behavior (adapters/<area>)
+   Verify: cargo test -p engram-<adapter>
+3. Facade/registry wiring
+   Verify: <the exact test that proves reachability>
+4. Agent surface (tool/skill/README)
+   Verify: <driver call or surface-parity check>
+```
+Steps without a verify command are wishes, not steps.
+
+### 5. Persist the plan AND the workflow
+```
+write_memory({ "content": "PLAN <slug>: <overview>. Precedents mined:
+  <what step 1 found>. Top risks: <...>. Steps: <N>, per-layer verify." })
+```
+If this feature type recurs, the successful shape becomes a procedure:
+
+```
+procedure_put({ "name": "add-<feature-type>",
+  "trigger": "new <feature-type> request",
+  "steps": ["<mine precedents>", "<map surface>", "<per-layer steps>",
+            "<verify each>", "<learn pass>"] })
+```
+
+## Output
+Overview / Findings (with the precedent search result — including
+"none found") / Risks (invariants + bridges) / Steps (per-layer) /
+Open Questions.
+
+## Stop conditions
+- Design contradicts an indexed `[proven]` invariant → stop; either
+  the invariant is wrong (an ADR-level change — say so) or the design
+  is. Don't plan past a contradiction.
+- No precedent found AND high blast radius → the first plan step is a
+  spike/prototype, explicitly labeled as such.

package/skills/engram-plan/references/plan-triage.md

@@ -0,0 +1,54 @@
+# Plan workflow: TRIAGE
+
+Rapid assessment of a reported problem. Triage does NOT fix — it
+classifies and routes. Time-boxed: if this takes more than a few tool
+calls, it's a bugfix, not a triage.
+
+## When this workflow
+- A bug/error report arrives with unclear severity
+- CI is red and nobody knows why
+- "Something is broken" with no repro
+
+## Steps
+
+### 1. Reproduce (or fail to, honestly)
+Run the failing thing. If you cannot reproduce, that IS the triage
+output: "not reproducible as described; likely <hypothesis [likely]>".
+
+### 2. Search the past (engram-search core move)
+```
+recall({ "query": "<error text core terms>" })
+search({ "query": "<failing symbol or area>" })
+procedure_list({})
+```
+- Has this exact failure happened before? (past fixes = fastest path)
+- Is there a known sharp edge here? (indexed `[proven]` memory)
+- Is there a runbook that already covers it?
+
+### 3. Classify
+
+| Class | Criteria | Route |
+|---|---|---|
+| Known + runbook exists | recall hit + procedure covers it | Follow the procedure; skip planning |
+| Known pattern, no runbook | similar past fix recalled | plan-bugfix (fast lane — the pattern is known) |
+| New failure mode | no past hits | plan-bugfix full workflow |
+| Not a bug (works as designed) | repro shows intended behavior | Report; maybe docs/engram-learn |
+| Severity: blocks release/CI | red main, broken publish | plan-bugfix immediately + flag urgency |
+
+### 4. Record the triage
+```
+write_memory({ "content": "TRIAGE <one-line>: <report> → <class>.
+  Root-cause hypothesis: <...> [likely]. Past evidence: <recall hit or
+  'none'>" })
+```
+If a runbook WAS missing but would have helped, note that — it feeds
+engram-learn later.
+
+## Output
+One paragraph: what was reported, what reproduced, the class, the
+route, the hypothesis. No fix, no plan steps — routing only.
+
+## Stop conditions
+- Cannot reproduce → report that, stop.
+- Runbook found → execute it, stop (that's not triage anymore).
+- Classification clear → hand to plan-bugfix, stop.

package/skills/engram-search/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: engram-search
+description: Agentic search over the code graph and memory to find or solve problems — "where is X", "how does Y work", "why did Z break", "find the code that...". An iterative hypothesis→retrieve→verify loop, not a one-shot lookup. Trigger on any codebase question where the answer should be evidenced.
+---
+
+# engram-search
+
+Answer codebase questions with evidence. A loop: **hypothesis → retrieve
+→ verify → refine**. Stop when the claim is `[proven]` — or honestly
+unproven.
+
+## Contract
+
+1. Never claim file contents from memory alone — verify with `fetch_content`.
+2. Every claim in the answer carries its evidence: the tool + query that proved it.
+3. Two fruitless iterations → say what you looked for and stop.
+4. Labels: `[proven]` (verified against source/graph), `[likely]` (strong signal, unverified), `[guessed]` (hypothesis only — say so).
+
+## Workflow
+
+### 1. State the hypothesis
+
+Before any tool call, write one line: *"I expect X lives in Y because Z."*
+This anchors the search and makes refinement measurable.
+
+### 2. Retrieve from two angles
+
+```
+recall({ "query": "<the question's key terms>" })
+search({ "query": "<the likely symbol/term name>" })
+```
+
+`recall` covers memories + knowledge + docs (the "why"); `search` covers
+the code graph (the "where").
+
+### 3. Drill the neighborhood
+
+For the best candidate symbol:
+
+```
+symbol_context({ "symbol": "<name>", "depth": 2 })
+```
+
+For an area rather than a symbol:
+
+```
+explore({ "query": "<area terms>", "depth": 2 })
+```
+
+### 4. Verify against source
+
+Before asserting what code does:
+
+```
+fetch_content({ "path": "<file path from the graph>" })
+```
+
+Graph and memory say where; the file says what. If they disagree, the
+index is stale — say so (`[likely]` at best).
+
+### 5. Refine or stop
+
+- Found and verified → answer.
+- Found but unverified → answer with `[likely]`, offer to fetch.
+- Nothing → refine the query with terms the graph revealed (community
+  names, related symbols), one more iteration. After two empty
+  iterations, report the queries tried and stop.
+
+## Output format
+
+```
+<answer, one paragraph>
+
+Evidence:
+- [proven] <claim> — symbol_context(X): called by A, B; fetch_content(file.rs)
+- [likely] <claim> — recall hit "…" (indexed Oct 2026; may be stale)
+- [guessed] <claim> — naming convention only
+```
+
+## When it fails
+
+- Empty store (no index yet) → say "not indexed; run engram-index or
+  scan_repo first" and stop. Do not fall back to grepping as if indexed.
+- Stale-index signals (symbols that no longer exist per `fetch_content`) →
+  flag the staleness in the answer; suggest `scan_repo`.
+- Ambiguous symbol (many same-name entities) → disambiguate with
+  `symbol_context` per candidate, or ask; don't average.
+
+## Anti-patterns
+
+- Claiming behavior from memory alone (no `fetch_content`).
+- One query, one give-up.
+- Answering from general language knowledge instead of this repo's graph.
+- Skipping the hypothesis line.
+
+## Final check
+
+- Is every claim labeled?
+- Did I read the actual file for the load-bearing claims?
+- Would the evidence chain convince a skeptical reviewer?