dsh-aris-panel 0.1.0

package/skills/skills-codex/embodiment-description/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: embodiment-description
+description: "Write detailed embodiment descriptions for patent specifications. Use when user says \"撰写实施例\", \"write embodiment\", \"实施例描述\", \"detailed description\", or wants to describe how to practice an invention."
+argument-hint: "[claims-path-or-embodiment-details]"
+allowed-tools: Bash(*), Read, Write, Edit, Grep, Glob
+---
+
+# Embodiment Description
+
+Write detailed embodiments for: **$ARGUMENTS**
+
+Embodiments describe HOW to make and use the invention -- they are the patent equivalent of experiment sections, but describe the invention rather than evaluating it empirically.
+
+## Constants
+
+- `MIN_EMBODIMENTS = 1` — At least one complete embodiment required
+- `MAX_EMBODIMENTS = 3` — Practical limit; more embodiments strengthen enablement
+- `EMBODIMENT_STYLE = detailed` — `detailed` (full working example) or `outline` (sketch)
+- `REFERENCE_NUMERAL_PREFIX = 100` — Starting reference numeral for first figure's components
+
+## Inputs
+
+1. `patent/INVENTION_DISCLOSURE.md` — invention decomposition (core/supporting/optional features)
+2. `patent/CLAIMS.md` — drafted claims that the embodiments must support
+3. User-provided figures (if any) in any directory
+4. `patent/figures/numeral_index.md` if it exists (from `/figure-description`)
+
+## Workflow
+
+### Step 1: Plan Embodiments
+
+For each claim category (method, system, etc.), plan at least one embodiment:
+
+| Embodiment | Covers Claims | Type | Key Variations |
+|-----------|--------------|------|----------------|
+| 1 | Claims 1, X | Best mode / preferred | [primary implementation] |
+| 2 | Claims 2, 3 | Alternative | [different parameters/materials] |
+| 3 | Claims 4, 5 | Additional alternative | [different configuration] |
+
+### Step 2: Write Each Embodiment
+
+For each embodiment, write a detailed description following this structure:
+
+**Opening paragraph**:
+"In one embodiment, [invention summary with reference to what is being described]."
+
+**Component/step-by-step description**:
+
+For method embodiments:
+- Describe each step in order
+- Reference figure numerals: "As shown in FIG. 1, at step 202, the processor 102 receives the input data 104..."
+- Include specific parameters, ranges, and conditions
+- Describe what happens at each decision point
+
+For system/apparatus embodiments:
+- Describe each component
+- Reference figure numerals: "Referring to FIG. 1, the system 100 comprises a processor 102, a memory 104, and a communication interface 106..."
+- Describe interconnections between components
+- Describe operation of the system step-by-step
+
+**Variations and alternatives**:
+- "In some embodiments, the processor 102 may be a GPU, an FPGA, or an ASIC."
+- "In another embodiment, the memory 104 may be replaced with a distributed storage system."
+- "The parameters described above are exemplary; other values within the range [X, Y] are also contemplated."
+
+These variations are critical -- they support broader claim interpretation.
+
+### Step 3: Reference Numeral Integration
+
+Ensure consistent reference numeral usage:
+
+1. Every component mentioned must have a numeral
+2. Numeral must appear first in parentheses after the component name: "the processor (102)"
+3. Subsequent references: "the processor 102" (no parentheses)
+4. Numbering follows figure series: 100-series for FIG. 1, 200-series for FIG. 2
+
+**Format**:
+- First mention: "the processor (102)"
+- Later in same embodiment: "the processor 102"
+- Cross-figure: "the processor 102 (shown in both FIG. 1 and FIG. 2)"
+
+### Step 4: Claim Support Verification
+
+For each claim element, verify it appears in at least one embodiment:
+
+| Claim Element | Embodiment | Reference Numeral | Description Paragraph |
+|---------------|-----------|-------------------|----------------------|
+| [element] | [which] | [numeral] | [paragraph reference] |
+
+If any claim element lacks embodiment support, add the necessary description.
+
+### Step 5: Software/Algorithm Embodiments (if applicable)
+
+For method/software inventions, include:
+- Pseudocode or algorithmic description (NOT actual code)
+- Flowchart description tied to figures
+- Data structure descriptions
+- Interface specifications
+
+Example:
+```
+In one embodiment, the method comprises the following steps:
+At step 202, the processor 102 receives input data from the input device 108.
+At step 204, the processor 102 extracts feature vectors from the input data using a convolutional neural network.
+At step 206, the processor 102 applies the attention mechanism 110 to the feature vectors...
+```
+
+### Step 6: Output
+
+Embodiment sections are written to `patent/specification/detailed_description.md` (or appended to the specification structure).
+
+Each embodiment section should be self-contained but cross-reference other embodiments when describing alternatives.
+
+## Key Rules
+
+- Embodiments must teach a POSITA to make and use the invention without undue experimentation.
+- Include at least one "best mode" embodiment (US requirement).
+- Multiple embodiments strengthen the specification against enablement challenges.
+- Describe the invention, do NOT evaluate it empirically ("The embodiment achieves 95% accuracy" is wrong; "The processor classifies the input data" is correct).
+- **CRITICAL — NO experimental data, test results, accuracy percentages, detection rates, precision values, or comparative performance data.** These belong in papers, not patents. The embodiment teaches HOW to make and use, not HOW WELL it performs.
+- WRONG: "传感器对直径超过150μm的金属颗粒实现了100%的检测精度，即使在检测限处仍保持94%的高精度。"
+- RIGHT: "当不锈钢颗粒通过间隙传感区域时，谐振频率下降。颗粒直径越大，频率偏移幅度越大。"
+- Do NOT include tables of experimental results, graphs of measurement data, or comparisons with prior art performance.
+- **CRITICAL — An embodiment is NOT an experiment.** Do NOT describe "repeated experiments", "accuracy evaluation", "precision testing", "calibration experiments", or "comparison with reference methods". An embodiment describes ONE way to make and use the invention — it is a recipe, not a test report.
+- Do NOT copy experimental sections from source papers verbatim. Transform the experimental setup into a manufacturing/operation description.
+- If the source material is a paper, extract ONLY: (1) what was built, (2) what materials/parameters were used, (3) how it operates. Ignore all test methodology, results, and performance metrics.
+- Include specific parameters where possible, but frame them as exemplary, not limiting.
+- Reference numerals must be consistent with the figures.
+- Do NOT use subjective language ("excellent", "surprising", "superior").

package/skills/skills-codex/exa-search/SKILL.md

@@ -0,0 +1,192 @@
+---
+name: exa-search
+description: AI-powered web search via Exa with content extraction. Use when user says "exa search", "web search with content", "find similar pages", or needs broad web results beyond academic databases (arXiv, Semantic Scholar).
+argument-hint: "[search-query-or-url]"
+allowed-tools: Bash(*), Read, Write
+---
+
+# Exa AI-Powered Web Search
+
+Search query: $ARGUMENTS
+
+## Role & Positioning
+
+Exa is the **broad web search** source with built-in content extraction:
+
+| Skill | Best for |
+|------|----------|
+| `/arxiv` | Direct preprint search and PDF download |
+| `/semantic-scholar` | Published venue papers (IEEE, ACM, Springer), citation counts |
+| `/deepxiv` | Layered reading: search, brief, section map, section reads |
+| `/exa-search` | Broad web search: blogs, docs, news, companies, research papers — with content extraction |
+
+Use Exa when you need results beyond academic databases, or when you want content (highlights, full text, summaries) extracted alongside search results.
+
+## Constants
+
+- **EXA_FETCHER** — canonical name `exa_search.py`, resolved per
+  [`shared-references/integration-contract.md`](../shared-references/integration-contract.md) §2
+  (Codex-side chain: `$ARIS_REPO/tools/` → `tools/` → `~/.codex/skills/exa-search/`).
+  Policy D1 — standalone `/exa-search` has no documented fallback,
+  so unresolved helper terminates with an explicit error.
+- **MAX_RESULTS = 10** — Default number of results to return.
+
+> Overrides (append to arguments):
+> - `/exa-search "RAG pipelines" — max: 5` — top 5 results
+> - `/exa-search "diffusion models" — category: research paper` — research papers only
+> - `/exa-search "startup funding" — category: news, start date: 2025-01-01` — recent news
+> - `/exa-search "transformer" — content: text, max chars: 8000` — full text mode
+> - `/exa-search "transformer" — content: summary` — LLM-generated summaries
+> - `/exa-search "transformer" — domains: arxiv.org,huggingface.co` — domain filter
+> - `/exa-search "https://arxiv.org/abs/2301.07041" — similar` — find similar pages
+
+## Setup
+
+Exa requires the `exa-py` SDK and an API key:
+
+```bash
+pip install exa-py
+```
+
+Set your API key:
+```bash
+export EXA_API_KEY=your-key-here
+```
+
+Get a key from [exa.ai](https://exa.ai).
+
+## Workflow
+
+### Step 1: Parse Arguments
+
+Parse `$ARGUMENTS` for:
+- **query**: The search query (required) or a URL (for `find-similar` mode)
+- **similar**: If present, use `find-similar` mode instead of search
+- **max**: Override MAX_RESULTS
+- **category**: `research paper`, `news`, `company`, `personal site`, `financial report`, `people`
+- **content**: `highlights` (default), `text`, `summary`, `none`
+- **max chars**: Max characters for content extraction
+- **type**: Search type — `auto` (default), `neural`, `fast`, `instant`
+- **domains**: Comma-separated include domains
+- **exclude domains**: Comma-separated exclude domains
+- **include text**: Phrase that must appear in results
+- **exclude text**: Phrase to exclude from results
+- **start date**: ISO 8601 date — only results after this
+- **end date**: ISO 8601 date — only results before this
+- **location**: Two-letter ISO country code
+
+### Step 2: Locate Script
+
+```bash
+# Resolve $EXA_FETCHER via the canonical strict-safe Codex chain.
+if [ -z "${ARIS_REPO:-}" ] && [ -f .aris/installed-skills-codex.txt ]; then
+    ARIS_REPO=$(awk -F'\t' '$1=="repo_root"{print $2; exit}' .aris/installed-skills-codex.txt 2>/dev/null) || true
+fi
+EXA_FETCHER=""
+[ -n "${ARIS_REPO:-}" ] && [ -f "$ARIS_REPO/tools/exa_search.py" ] && EXA_FETCHER="$ARIS_REPO/tools/exa_search.py"
+[ -z "$EXA_FETCHER" ] && [ -f tools/exa_search.py ] && EXA_FETCHER="tools/exa_search.py"
+[ -z "$EXA_FETCHER" ] && [ -f ~/.codex/skills/exa-search/exa_search.py ] && EXA_FETCHER="$HOME/.codex/skills/exa-search/exa_search.py"
+[ -z "$EXA_FETCHER" ] && {
+  echo "ERROR: exa_search.py not resolved at \$ARIS_REPO/tools/, tools/, or ~/.codex/skills/exa-search/." >&2
+  echo "       Fix: rerun tools/install_aris_codex.sh, export ARIS_REPO, or copy the helper to ~/.codex/skills/exa-search/." >&2
+  echo "       Also ensure 'exa-py' is installed: pip install exa-py" >&2
+  exit 1
+}
+```
+
+If not found, tell the user:
+```
+exa_search.py not found. Run install_aris_codex.sh, set ARIS_REPO to your ARIS repo root, or install/copy the helper into the project/global Codex skill path; then install exa-py:
+pip install exa-py
+```
+
+### Step 3: Execute Search
+
+**Standard search:**
+```bash
+python3 "$EXA_FETCHER" search "QUERY" --max 10 --content highlights
+```
+
+**With filters:**
+```bash
+python3 "$EXA_FETCHER" search "QUERY" --max 10 \
+  --category "research paper" \
+  --start-date 2025-01-01 \
+  --content text --max-chars 8000
+```
+
+**Find similar pages:**
+```bash
+python3 "$EXA_FETCHER" find-similar "URL" --max 5 --content highlights
+```
+
+**Get content for known URLs:**
+```bash
+python3 "$EXA_FETCHER" get-contents "URL1" "URL2" --content text
+```
+
+### Step 4: Present Results
+
+Format results as a structured table:
+
+```
+| # | Title | Authors | Venue/Publisher | URL | Date | Key Content |
+|---|-------|---------|-----------------|-----|------|-------------|
+```
+
+For each result:
+- Show title and URL
+- Show published date if available
+- Show highlights, text excerpt, or summary depending on content mode
+- Flag particularly relevant results
+- **For `category: "research paper"` hits only** — also record authors
+  (from Exa's `author`/`authors` fields, or fallback: parse from the
+  result snippet) and venue/publisher (from `publisher`, `source`, or
+  the domain hosting the paper). These are needed by Step 6's wiki
+  hook; if either is unavailable for a given hit, skip wiki ingest
+  for that one hit and log a note.
+
+### Step 5: Offer Follow-up
+
+After presenting results, suggest:
+- **Deepen**: "I can fetch full text for any of these results"
+- **Find similar**: "I can find pages similar to any result"
+- **Narrow**: "I can re-search with domain/date/text filters"
+
+### Step 6: Update Research Wiki (if active, research-paper results only)
+
+**Required when `research-wiki/` exists AND the search returned
+results of `category: "research paper"`**; skip silently otherwise.
+General web results (blog posts, docs, news) are **not** ingested —
+the wiki is for papers only.
+
+For each research paper hit, try to recover an arXiv ID from the URL
+(`arxiv.org/abs/<id>`); if present, use `--arxiv-id`. Otherwise fall
+back to manual metadata:
+
+```
+if [ -d research-wiki/ ] and query category was "research paper":
+    WIKI_SCRIPT=""
+    [ -n "$ARIS_REPO" ] && [ -f "$ARIS_REPO/tools/research_wiki.py" ] && WIKI_SCRIPT="$ARIS_REPO/tools/research_wiki.py"
+    [ -z "$WIKI_SCRIPT" ] && [ -f tools/research_wiki.py ] && WIKI_SCRIPT="tools/research_wiki.py"
+    [ -z "$WIKI_SCRIPT" ] && [ -f ~/.codex/skills/research-wiki/research_wiki.py ] && WIKI_SCRIPT="$HOME/.codex/skills/research-wiki/research_wiki.py"
+    for each research-paper hit in results:
+        if URL matches arxiv.org/abs/<id>:
+            [ -n "$WIKI_SCRIPT" ] && python3 "$WIKI_SCRIPT" ingest_paper research-wiki/ \
+                --arxiv-id "<id>"
+        else:
+            [ -n "$WIKI_SCRIPT" ] && python3 "$WIKI_SCRIPT" ingest_paper research-wiki/ \
+                --title "<title>" --authors "<authors joined by , >" \
+                --year <year> --venue "<venue or publisher>"
+```
+
+The helper handles slug / dedup / page / index / log — **do not
+handwrite `papers/<slug>.md`**. See
+[`shared-references/integration-contract.md`](../shared-references/integration-contract.md).
+
+## Key Rules
+- Always check that `EXA_API_KEY` is set before searching
+- Default to `highlights` content mode for a good balance of speed and context
+- Use `category: "research paper"` when the user is clearly looking for academic content
+- Use `text` content mode when the user needs full page content
+- Combine with `/arxiv` or `/semantic-scholar` for comprehensive literature coverage

package/skills/skills-codex/experiment-audit/SKILL.md

@@ -0,0 +1,286 @@
+---
+name: experiment-audit
+description: "Audit experiment integrity before claiming results. Uses fresh-agent GPT-5.6-Sol review (same-family provisional in the base Codex mirror) to check for fake ground truth, score normalization fraud, phantom results, and insufficient scope. Use when user says \"审计实验\", \"check experiment integrity\", \"audit results\", \"实验诚实度\", or after experiments complete before writing claims."
+argument-hint: "[experiment-dir-or-results-path]"
+allowed-tools: Bash(*), Read, Write, Edit, Grep, Glob
+---
+
+# Experiment Audit: Fresh-Agent Integrity Verification
+
+> **Codex assurance:** base semantic audit results record
+> `review_independence: same-family` and `acceptance_status: provisional`.
+> Deterministic evidence checks may be accepted; unavailable reviewer calls emit
+> BLOCKED/ERROR rather than a provisional PASS.
+
+Audit experiment integrity for: **$ARGUMENTS**
+
+## Why This Exists
+
+LLM agents can produce fraudulent experimental results through:
+1. **Fake ground truth** — creating synthetic "reference" from model outputs, then reporting high agreement as performance
+2. **Score normalization** — dividing metrics by the model's own max to get 0.99+
+3. **Phantom results** — claiming numbers from files that don't exist or functions never called
+4. **Insufficient scope** — reporting 2-scene pilots as "comprehensive evaluation"
+
+These are NOT intentional deception — they are failure modes of optimizing agents that lack integrity constraints. This skill adds that constraint.
+
+## Core Principle
+
+**The executor (Codex) collects file paths. A fresh Codex reviewer reads code and judges integrity. The executor does NOT participate in integrity judgment; this base route is same-family/provisional.**
+
+This follows `shared-references/reviewer-independence.md` and `shared-references/experiment-integrity.md`.
+
+## Constants
+
+- **REVIEWER_BACKEND = `codex`** — Default: Codex reviewer agent (`spawn_agent`, ultra — deep-audit tier). Override with `— reviewer: oracle-pro` for GPT-5.5 Pro via Oracle MCP. See `shared-references/reviewer-routing.md`.
+
+## Workflow
+
+### Step 1: Collect Artifacts (Executor — Codex)
+
+Locate and list these files WITHOUT reading or summarizing their content:
+
+```
+Scan project directory for:
+1. Evaluation scripts:    *eval*.py, *metric*.py, *test*.py, *benchmark*.py
+2. Result files:          *.json, *.csv in results/, outputs/, logs/
+3. Ground truth paths:    look in eval scripts for data loading (dataset paths, GT references)
+4. Experiment tracker:    EXPERIMENT_TRACKER.md, EXPERIMENT_LOG.md
+5. Paper claims:          NARRATIVE_REPORT.md, paper/sections/*.tex, PAPER_PLAN.md
+6. Config files:          *.yaml, *.toml, *.json configs with metric definitions
+```
+
+**DO NOT summarize, interpret, or explain any file content.** Only collect paths.
+
+### Step 2: Send to Reviewer (GPT-5.6-Sol via Codex MCP)
+
+Pass ONLY file paths and the audit checklist to the reviewer. The reviewer reads everything directly.
+
+```text
+spawn_agent:
+  model: gpt-5.6-sol
+  reasoning_effort: ultra
+  message: |
+    You are an experiment integrity auditor. Start from the assumption that the
+    evaluation is compromised somewhere — your job is to find where. Be
+    adversarial. Trust nothing the author tells you — verify everything
+    yourself. Read ALL files listed below and check for the following fraud
+    patterns.
+
+    Files to read:
+    - Evaluation scripts: [list paths]
+    - Result files: [list paths]
+    - Experiment tracker: [list paths]
+    - Paper claims: [list paths]
+    - Config files: [list paths]
+
+    ## Audit Checklist
+
+    ### A. Ground Truth Provenance
+    For each evaluation script:
+    1. Where does "ground truth" / "reference" / "target" come from?
+    2. Is it loaded from the DATASET, or generated/derived from MODEL OUTPUTS?
+    3. If derived: is it explicitly labeled as proxy evaluation?
+    4. Are official eval scripts used when available for this benchmark?
+    FAIL if: GT is derived from model outputs without explicit proxy labeling.
+
+    ### B. Score Normalization
+    For each metric computation:
+    1. Is any metric divided by max/min/mean of the model's OWN output?
+    2. Are raw scores reported alongside any normalized scores?
+    3. Are any scores suspiciously close to 1.0 or 100%?
+    FAIL if: Normalization denominator comes from prediction statistics.
+
+    ### C. Result File Existence
+    For each claim in the paper/narrative:
+    1. Does the referenced result file actually exist?
+    2. Does the claimed metric key exist in that file?
+    3. Does the claimed NUMBER match what's in the file?
+    4. Is the experiment tracker status DONE (not TODO/IN_PROGRESS)?
+    FAIL if: Claimed results reference nonexistent files or mismatched numbers.
+
+    ### D. Dead Code Detection
+    For each metric function defined in eval scripts:
+    1. Is it actually CALLED in any evaluation pipeline?
+    2. Does its output appear in any result file?
+    WARN if: Metric functions exist but are never called.
+
+    ### E. Scope Assessment
+    1. How many scenes/datasets/configurations were actually tested?
+    2. How many seeds/runs per configuration?
+    3. Does the paper use words like "comprehensive", "extensive", "robust"?
+    4. Is the actual scope sufficient for those claims?
+    WARN if: Scope language exceeds actual evidence.
+
+    ### F. Evaluation Type Classification
+    Classify each evaluation as:
+    - real_gt: uses dataset-provided ground truth
+    - synthetic_proxy: uses model-generated reference
+    - self_supervised_proxy: no GT by design
+    - simulation_only: simulated environment
+    - human_eval: human judges
+
+    ## Output Format
+
+    For each check (A-F), report:
+    - Status: PASS | WARN | FAIL
+    - Evidence: exact file:line references
+    - Details: what specifically was found
+
+    Overall verdict: PASS | WARN | FAIL
+    
+    Be thorough. Read every eval script line by line.
+```
+
+### Step 3: Parse and Write Report (Executor — Codex)
+
+Parse the reviewer's response and write `EXPERIMENT_AUDIT.md`:
+
+```markdown
+# Experiment Audit Report
+
+**Date**: [today]
+**Auditor**: GPT-5.6-Sol ultra (fresh same-family agent, read-only, provisional)
+**Project**: [project name]
+
+## Overall Verdict: [PASS | WARN | FAIL]
+
+## Integrity Status: [pass | warn | fail]
+
+## Checks
+
+### A. Ground Truth Provenance: [PASS|WARN|FAIL]
+[details + file:line evidence]
+
+### B. Score Normalization: [PASS|WARN|FAIL]
+[details]
+
+### C. Result File Existence: [PASS|WARN|FAIL]
+[details]
+
+### D. Dead Code Detection: [PASS|WARN|FAIL]
+[details]
+
+### E. Scope Assessment: [PASS|WARN|FAIL]
+[details]
+
+### F. Evaluation Type: [real_gt | synthetic_proxy | ...]
+[classification + evidence]
+
+## Action Items
+- [specific fixes if WARN or FAIL]
+
+## Claim Impact
+- Claim 1: [supported | needs qualifier | unsupported]
+- Claim 2: ...
+```
+
+Also write `EXPERIMENT_AUDIT.json` for machine consumption:
+
+```json
+{
+  "audit_skill": "experiment-audit",
+  "verdict": "WARN",
+  "reason_code": "scope_exceeds_evidence",
+  "summary": "Two-scene evaluation supports a qualified claim only.",
+  "audited_input_hashes": {"results/eval.json": "sha256:<hash>"},
+  "trace_path": ".aris/traces/experiment-audit/2026-04-10_run01/",
+  "agent_id": "agent_019f...",
+  "verdict_id": "agent_019f...",
+  "executor_model": "codex-gpt-5.6-sol",
+  "executor_family": "openai",
+  "reviewer_model": "gpt-5.6-sol",
+  "reviewer_family": "openai",
+  "reviewer_reasoning": "ultra",
+  "review_independence": "same-family",
+  "acceptance_status": "provisional",
+  "generated_at": "2026-04-10T00:00:00Z",
+  "date": "2026-04-10",
+  "auditor": "gpt-5.6-sol-ultra",
+  "overall_verdict": "warn",
+  "integrity_status": "warn",
+  "checks": {
+    "gt_provenance": {"status": "pass", "details": "..."},
+    "score_normalization": {"status": "warn", "details": "..."},
+    "result_existence": {"status": "pass", "details": "..."},
+    "dead_code": {"status": "pass", "details": "..."},
+    "scope": {"status": "warn", "details": "..."},
+    "eval_type": "real_gt"
+  },
+  "claims": [
+    {"id": "C1", "impact": "supported"},
+    {"id": "C2", "impact": "needs_qualifier"}
+  ]
+}
+```
+
+### Step 4: Print Summary
+
+```
+🔬 Experiment Audit Complete
+
+  GT Provenance:      ✅ PASS — real dataset GT used
+  Score Normalization: ⚠️ WARN — boundary metric uses self-reference
+  Result Existence:    ✅ PASS — all files exist, numbers match
+  Dead Code:           ✅ PASS — all metric functions called
+  Scope:               ⚠️ WARN — 2 scenes, paper says "comprehensive"
+
+  Overall: ⚠️ WARN
+  
+  See EXPERIMENT_AUDIT.md for details.
+```
+
+## Integration with Other Skills
+
+### Automatic in /research-pipeline (advisory, never blocks)
+
+When integrated into the pipeline, this skill runs automatically after `/experiment-bridge` and before `/auto-review-loop`:
+
+```
+/experiment-bridge → results ready
+    ↓
+/experiment-audit (automatic, advisory)
+    ├── PASS  → continue normally
+    ├── WARN  → print ⚠️ warning, continue, tag claims as [INTEGRITY: WARN]
+    └── FAIL  → print 🔴 alert, continue, tag claims as [INTEGRITY CONCERN]
+    ↓
+/auto-review-loop → proceeds with integrity tags visible to reviewer
+```
+
+**Never blocks the pipeline.** Even on FAIL, the pipeline continues — but claims carry visible integrity tags.
+
+### Read by /result-to-claim (if exists)
+
+```
+if EXPERIMENT_AUDIT.json exists:
+    read integrity_status
+    attach to verdict: {claim_supported: "yes", integrity_status: "warn"}
+    if integrity_status == "fail":
+        downgrade verdict display: "yes [INTEGRITY CONCERN]"
+else:
+    verdict as normal, integrity_status = "unavailable"
+    mark as "provisional — no integrity audit"
+```
+
+### Read by /paper-write (if exists)
+
+```
+if EXPERIMENT_AUDIT.json exists AND integrity_status == "fail":
+    add footnote to affected claims: "Note: integrity audit flagged concerns with this evaluation"
+```
+
+## Key Rules
+
+- **Reviewer independence**: executor collects paths, reviewer judges. Period.
+- **Never block**: warn loudly, never halt the pipeline.
+- **File-as-switch**: no EXPERIMENT_AUDIT.md = skill was never run = zero impact on existing behavior.
+- **Review class**: base Codex is same-family provisional; only an overlay may claim cross-family accepted.
+- **Honest about limits**: the audit catches common patterns, not all possible fraud. It is a safety net, not a guarantee.
+
+## Acknowledgements
+
+Motivated by community-reported integrity issues (#57, #131) where executor agents created fake ground truth and self-normalized scores.
+
+## Review Tracing
+
+After each reviewer agent call, save the trace following `shared-references/review-tracing.md` (Policy C — forensic; never silently skip). Use `save_trace.sh` (resolved per the chain in `shared-references/integration-contract.md` §2) or write files directly to `.aris/traces/<skill>/<date>_run<NN>/`. Respect the `--- trace:` parameter (default: `full`).