dsh-aris-panel 0.1.0

package/skills/shared-references/skill-governance.md

@@ -0,0 +1,104 @@
+# Skill Governance: Provenance-as-Authorization
+
+When ARIS **auto-writes** a durable artifact — a meta-optimize patch to a SKILL.md,
+an auto-curated research-wiki node, a machine-proposed reviewer prompt — two
+questions must have a recorded, checkable answer *before* that artifact is allowed
+to influence future runs:
+
+1. **Who authored it, and who acquitted it?** (and were they different model families?)
+2. **Is auto-curation even allowed to touch this file?** (or is it a hand-written
+   canonical skill / a user's own note, which automation must never rewrite?)
+
+`tools/provenance.py` is the primitive that answers both. This is the
+**provenance-as-authorization boundary**: a provenance record is not just metadata,
+it *is* the authorization to auto-curate.
+
+## The rule
+
+- **Auto-curation may ONLY touch artifacts where `is_auto_authored(path)` is True.**
+  An auto-authored artifact carries a `.provenance.json` sidecar with
+  `created_by == "aris-auto"`. Canonical hand-written skills and user notes have no
+  such record — `is_auto_authored` returns False — and are **off-limits** to any
+  automated rewrite/delete. (A loop can author new machine artifacts; it must not
+  silently edit human ones.)
+
+- **A provenance record cannot be same-family.** `stamp()` calls
+  `assert_cross_family(author, reviewer)` and **refuses (raises)** if the author and
+  the reviewer are the same model family — e.g. `claude`+`sonnet`, or `gpt-5.6-sol`+`codex`,
+  or the trap `gpt-5.6-sol`+`oracle-pro` (oracle routes to a GPT-Pro tier, so it is the
+  **openai** family, not a separate one). You therefore *cannot produce* a valid
+  authorization for a self-acquitted artifact. This is the structural form of the
+  cross-model invariant from [`reviewer-independence.md`](reviewer-independence.md)
+  and the acceptance boundary from [`acceptance-gate.md`](acceptance-gate.md):
+  **a loop can DRIVE, it cannot ACQUIT itself.**
+
+- **A deterministic verifier is a valid reviewer.** A reviewer named
+  `deterministic:<verifier>` (e.g. `deterministic:evidence_check`,
+  `deterministic:pytest`) passes the gate regardless of the author — a process is
+  not a model family. This is the same Type-A escape hatch as in
+  [`acceptance-gate.md`](acceptance-gate.md): an execution-completeness / mechanical
+  check is safe same-model. Use it when the acquittal is a passing test or a
+  deterministic pre-check (see [`evidence-precheck.md`](evidence-precheck.md)), not a
+  semantic judgement.
+
+- **Unknown family fails closed.** If either name maps to no known family,
+  `assert_cross_family` raises rather than guessing — you must use a recognized
+  reviewer or a deterministic verifier.
+
+## The record
+
+`stamp(target, author_model, reviewer_model, verdict_id)` writes:
+
+```json
+{
+  "created_by": "aris-auto",
+  "author_model": "claude-opus-4-8",
+  "author_family": "anthropic",
+  "reviewer_model": "gpt-5.6-sol",
+  "reviewer_family": "openai",
+  "verdict_id": "codex_thread_abc123",
+  "content_hash": "<sha256 of the artifact>",
+  "stamped_at": "2026-05-30T00:00:00Z"
+}
+```
+
+- `verdict_id` is the **traceable** acquittal — the codex thread id, the oracle
+  session id, or for a deterministic reviewer the verifier report path / sha. It is
+  required (empty → refused), so every authorization points back to an auditable
+  review.
+- `content_hash` is tamper-evidence: if the artifact is later edited by hand, the
+  hash no longer matches the record, and a re-stamp (= a fresh cross-model review)
+  is required before auto-curation may treat it as machine-owned again.
+
+## How skills use it
+
+- **meta-optimize** — when an auto-patch lands (Step 6), `stamp()` the changed
+  SKILL.md with `author_model` = the executor that drafted the patch and
+  `reviewer_model` = the codex/oracle reviewer that scored it (Step 4). The stamp
+  *refusing* is the last line of defense: if the patch was never cross-model
+  reviewed, there is no valid `verdict_id`/family pair to stamp, so it cannot be
+  recorded as authorized.
+- **research-wiki** — auto-curated nodes (machine-merged, machine-pruned) get a
+  provenance stamp; user-written and import-from-paper nodes do not, so a future
+  auto-curator can tell which nodes it is allowed to rewrite.
+- **acceptance-gate** — the cross-family assertion here is the *enforcement* of the
+  Type-B (quality/correctness) rule: a quality acquittal of an auto-authored
+  artifact must be cross-model, and the provenance record is the proof that it was.
+
+## Why (the Hermes contrast)
+
+Hermes-agent (NousResearch, MIT) has the *shape* — a `skill_provenance` marker and
+a `created_by` tag — but its cross-model curator is **optional config that defaults
+to the same chat model**, so by default one model writes, judges, and consumes its
+own skills. That is exactly the self-poisoning failure
+[`capture-antipatterns.md`](capture-antipatterns.md) guards against, one level up:
+there it is a *captured claim* that hardens into a self-cited falsehood; here it is
+a *captured skill* that an unreviewed loop grants itself authority to keep. ARIS's
+increment is to make cross-family a **structural assertion on the stamp's content**:
+`assert_cross_family` genuinely raises, so you cannot produce a *valid* same-family stamp
+(not a config flag you can flip). The scope is precise — this governs *what a stamp can
+say*, not *whether a write calls `stamp()` at all*. Whether a corpus mutation is stamped
+is governed by `/meta-apply`'s landing procedure; an edit that skips the stamp leaves no
+provenance — that case is **detectable, not impossible** (a missing / stale-hash stamp is
+what a pre-push integrity check would catch — that verifier is a follow-up, see
+meta-optimize's note).

package/skills/shared-references/taste-calibration.md

@@ -0,0 +1,85 @@
+# Taste Calibration Protocol
+
+> Subjective quality is gradable **if you write the taste down and anchor the
+> scale**. The model will not invent taste; it will only converge toward the
+> taste you described — so the whole game is (1) a weighted rubric worth
+> converging to, and (2) reference anchors that pin what "good" and "slop"
+> actually look like. (After Karpathy's LOOPS.md VI, "score the subjective".)
+
+Use this protocol whenever a skill grades an artifact on axes that are matters
+of judgment — visual design, writing elegance, proposal quality — rather than
+machine-checkable facts. It layers ON TOP of any deterministic gates the skill
+already has (hard caps, measurement gates); it never replaces them.
+
+## 1. Named axes with explicit numeric weights
+
+Define 2–7 named axes and give each an explicit weight; weights sum to 1.0.
+Model the table on `research-refine`'s working precedent (its Phase 2 uses
+15/25/25/15/10/5/5% across seven axes):
+
+```markdown
+| Axis          | Weight | What it measures                                  |
+|---------------|:------:|---------------------------------------------------|
+| Design        |  0.35  | hierarchy, spacing, restraint, gestalt            |
+| Originality   |  0.15  | distinct voice vs template sameness               |
+| Craft         |  0.30  | detail quality: typography, alignment, math, figs |
+| Functionality |  0.20  | does it do its job (readable at distance, ...)    |
+```
+
+Score each axis 0–1 (or 1–10 rescaled). Composite = Σ weightᵢ · axisᵢ. A single
+holistic number without named weighted axes is not this protocol.
+
+## 2. Calibrate on reference anchors BEFORE scoring the target
+
+The grader first scores **3 known-good and 3 known-bad reference exemplars** on
+the same axes, so the scale is anchored to concrete artifacts instead of the
+grader's free-floating prior.
+
+- References are **pre-existing, human-curated files** — the executor never
+  selects, generates, or searches for anchors itself (an executor-picked anchor
+  set just smuggles the free-floating prior back in). The invoking skill
+  supplies the paths — convention: `<skill-dir>/references/good/` and
+  `<skill-dir>/references/bad/` (images, PDFs, or text artifacts of the same
+  kind as the target). Project-local references may override the skill-local
+  set.
+- The grader is TOLD which set is which ("these three are good, these three are
+  slop") — calibration is about anchoring the scale, not blind classification.
+- Sanity check: if the calibrated scores don't separate the sets (a "bad"
+  exemplar scores at or above a "good" one on the composite), the rubric is
+  broken — fix the rubric before trusting any target score.
+
+**Graceful degradation:** if no reference sets exist, proceed with the weighted
+rubric alone, but the output MUST carry `calibration: none` so a downstream
+reader never mistakes an unanchored score for an anchored one. Do not fabricate
+or hallucinate reference scores.
+
+## 3. Output contract
+
+```
+COMPOSITE: 0.xx            (weighted; also give per-axis scores)
+CALIBRATION: anchored | none
+GAP: <one mandatory paragraph naming WHICH reference exemplar(s) the target
+     falls short of or exceeds, on WHICH axes, and why — "0.71 because the
+     figure hierarchy matches good/poster_B but the typography is closer to
+     bad/poster_A's crowding" — never just a number>
+```
+
+The GAP paragraph is what makes the score actionable: converging toward the
+described taste requires knowing where the artifact sits relative to the
+anchors, not just its scalar.
+
+## 4. Interaction with existing gates and the jury
+
+- **Deterministic caps stay hard floors.** A calibrated composite never
+  overrides a measurement gate or critical cap (e.g. paper-poster-html's
+  "< 2 real figures → ≤ 3"). Compute caps first; the composite lives under
+  them.
+- **Calibration ≠ acquittal.** A taste score produced by the executor's own
+  model family may DRIVE the fix loop (rank issues, decide what to patch next)
+  but can never acquit: wherever a skill's acceptance requires a cross-model
+  verdict, that requirement is unchanged. (Per `acceptance-gate.md`'s taxonomy
+  a model-assigned score is a semantic judgment — calibration narrows its
+  variance; it does not make it machine-checkable.)
+- **Rubric drift is meta-optimize's job.** If users repeatedly override
+  calibrated scores, the rubric or the anchors are wrong — that's an event-log
+  signal for `/meta-optimize`, not a reason to hand-tweak scores per run.

package/skills/shared-references/venue-checklists.md

@@ -0,0 +1,114 @@
+# Venue Checklists for ICLR, NeurIPS, ICML, and IEEE
+
+Use this reference near the end of `paper-plan` and during the final checks in `paper-write`.
+
+## When to Read
+
+- Read once when setting the target venue.
+- Read again before locking the outline.
+- Read again during final submission-readiness checks.
+
+## Universal Requirements
+
+Across these venues, the following are usually expected:
+
+- anonymous submission unless preparing a camera-ready version,
+- references and appendices outside the main page budget,
+- enough experimental detail for reproduction,
+- honest limitations and scope boundaries,
+- clear mapping from claims to evidence.
+
+## NeurIPS
+
+Planning implications:
+
+- The paper checklist is mandatory.
+- Claims in the Abstract and Introduction must align with the actual evidence.
+- The paper should discuss limitations honestly.
+- Reproducibility details, hyperparameters, data access, and compute usage should be documented.
+- Statistical reporting should specify error bars, number of runs, and how uncertainty is computed.
+
+Final-check implications:
+
+- Confirm the paper checklist is complete.
+- Ensure limitations, reproducibility details, and compute reporting exist somewhere appropriate.
+- Verify theory papers include assumptions and full proofs in the main paper or appendix.
+
+## ICML
+
+Planning implications:
+
+- The paper must budget space for an ICML-style Broader Impact statement.
+- Reproducibility expectations are strong: data splits, hyperparameters, search ranges, and compute should be documented.
+- Statistical reporting should state whether uncertainty uses standard deviation, standard error, or confidence intervals.
+
+Final-check implications:
+
+- Ensure the Broader Impact statement is present in the expected location.
+- Confirm anonymization is strict: no author names, acknowledgments, grant IDs, or self-identifying repository links.
+- Verify experimental details are detailed enough for replication.
+
+## ICLR
+
+Planning implications:
+
+- Reproducibility and ethics statements are often recommended even if not always mandatory.
+- If LLMs materially contributed to ideation or writing to the point of authorship-like contribution, plan a disclosure section or appendix note.
+- Keep the story front-loaded because ICLR reviewers often judge quickly from the early pages.
+
+Final-check implications:
+
+- Decide whether LLM disclosure is required for this project.
+- Confirm the paper includes enough reproducibility guidance, code/data availability information, and limitations discussion.
+- Check that the contribution is already clear by the end of the Introduction.
+
+## IEEE Journal (Transactions / Letters)
+
+Planning implications:
+
+- IEEE journals are typically **not anonymous** — include full author names, affiliations, and IEEE membership status from submission.
+- Use `\documentclass[journal]{IEEEtran}` with `\cite{}` (numeric citations via `cite` package). Do NOT use `natbib`.
+- References **count toward the page limit**. IEEE Transactions typically allow 12-14 pages total; IEEE Letters (e.g., WCL, CL, SPL) typically allow 4-5 pages total. Check the specific journal's author guidelines.
+- Include an `\begin{IEEEkeywords}` block immediately after the abstract.
+- The bibliography style must be `IEEEtran.bst` (produces numeric `[1]` style citations).
+- IEEE journals may require a biosketch (`\begin{IEEEbiography}`) for each author in the camera-ready version.
+- Some IEEE journals require a cover letter addressing how the paper differs from conference versions (if applicable).
+
+Final-check implications:
+
+- Confirm author names and IEEE membership grades are correct (Member, Senior Member, Fellow).
+- Verify the total page count including references is within the journal's limit.
+- Check that all figures meet IEEE quality requirements: 300 dpi minimum, proper axis labels, readable when printed in grayscale.
+- Ensure the paper uses two-column IEEE format throughout (the `[journal]` option handles this).
+- Verify no `\citep` or `\citet` commands are present — IEEE uses `\cite{}` only.
+- Check that `\bibliographystyle{IEEEtran}` is used.
+
+## IEEE Conference (ICC, GLOBECOM, INFOCOM, ICASSP, etc.)
+
+Planning implications:
+
+- Most IEEE conferences are **not anonymous** (except some like IEEE S&P). Include full author information.
+- Use `\documentclass[conference]{IEEEtran}` with `\cite{}` (numeric citations).
+- References **count toward the page limit**. Typical limit: 5-6 pages (e.g., ICC, GLOBECOM), some allow up to 8 pages (e.g., INFOCOM). Extra pages may incur additional charges.
+- Include `\begin{IEEEkeywords}` after the abstract.
+- Conference papers do NOT include author biographies.
+- Some IEEE conferences accept 2-page extended abstracts — confirm the paper category before planning.
+
+Final-check implications:
+
+- Verify total page count including references fits within the conference limit.
+- Check that figures are readable at the two-column conference format size.
+- Ensure `\bibliographystyle{IEEEtran}` is used.
+- Verify no `\citep` or `\citet` commands are present.
+- Confirm the correct `\documentclass` option (`[conference]`, not `[journal]`).
+- Some conferences require IEEE copyright notice — check submission portal for specific requirements.
+
+## Minimal Submission Checklist
+
+Before submission, verify:
+
+- the venue-specific required sections are present,
+- the page budget is satisfied for the main body,
+- the contribution bullets do not overclaim,
+- citations, figures, tables, and references are internally consistent,
+- the PDF is anonymized and ready for reviewer consumption.

package/skills/shared-references/wiki-helper-resolution.md

@@ -0,0 +1,134 @@
+# Wiki helper resolution chain
+
+Canonical resolution chain for the research-wiki helper. Used by every
+SKILL that touches the wiki — never hard-code `python3 tools/research_wiki.py`,
+because that silently fails when `<project>/tools/` is not on disk
+(the post-`install_aris.sh` default), exactly the failure mode that
+left a real user's `research-wiki/` empty for a week.
+
+## The chain
+
+```bash
+cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" || exit 1
+ARIS_REPO="${ARIS_REPO:-$(awk -F'\t' '$1=="repo_root"{print $2; exit}' .aris/installed-skills.txt 2>/dev/null)}"
+# Layer 4: global pointer file written by the installer/updater at
+# ~/.aris/repo (#366) — covers global copy-installs with no project manifest.
+if [ -z "${ARIS_REPO:-}" ] && [ -f "$HOME/.aris/repo" ]; then
+    ARIS_REPO=$(cat "$HOME/.aris/repo" 2>/dev/null) || true
+fi
+WIKI_SCRIPT=".aris/tools/research_wiki.py"
+[ -f "$WIKI_SCRIPT" ] || WIKI_SCRIPT="tools/research_wiki.py"
+[ -f "$WIKI_SCRIPT" ] || { [ -n "${ARIS_REPO:-}" ] && WIKI_SCRIPT="$ARIS_REPO/tools/research_wiki.py"; }
+```
+
+After the chain runs, exactly one of two outcomes:
+
+- `[ -f "$WIKI_SCRIPT" ]` → helper located, use as `python3 "$WIKI_SCRIPT" <subcommand>`
+- `[ ! -f "$WIKI_SCRIPT" ]` → helper missing; pick a variant below
+
+## Variant A — hard-fail (for `/research-wiki` itself)
+
+The skill **is** the wiki tool. If the helper is missing, fail loudly.
+
+```bash
+[ -f "$WIKI_SCRIPT" ] || {
+  echo "ERROR: research_wiki.py not found at .aris/tools/, tools/, \$ARIS_REPO/tools/, or via ~/.aris/repo." >&2
+  echo "       Fix one of:" >&2
+  echo "         1. rerun 'bash tools/install_aris.sh' from the ARIS repo (creates .aris/tools symlink, refreshes ~/.aris/repo)" >&2
+  echo "         2. rerun 'bash tools/smart_update.sh' (refreshes ~/.aris/repo)" >&2
+  echo "         3. export ARIS_REPO=<path-to-ARIS-repo>" >&2
+  echo "         4. cp <ARIS-repo>/tools/research_wiki.py tools/" >&2
+  exit 1
+}
+```
+
+## Variant B — warn + skip (for caller skills)
+
+Used by `/idea-creator`, `/result-to-claim`, `/research-lit`, `/arxiv`,
+`/alphaxiv`, `/deepxiv`, `/exa-search`, `/semantic-scholar`. The
+skill's primary output (idea ranking, claim verdict, paper summary)
+must still be delivered to the user; only the wiki side-effect is
+skipped.
+
+```bash
+[ -f "$WIKI_SCRIPT" ] || {
+  echo "WARN: research_wiki.py not found at .aris/tools/, tools/, \$ARIS_REPO/tools/, or via ~/.aris/repo." >&2
+  echo "      Primary output will still be produced; wiki update is skipped." >&2
+  echo "      Fix: rerun 'bash tools/install_aris.sh' or 'smart_update.sh' (refreshes ~/.aris/repo), export ARIS_REPO, or 'cp <ARIS-repo>/tools/research_wiki.py tools/'." >&2
+  WIKI_SCRIPT=""
+}
+```
+
+After Variant B, every helper invocation must be guarded:
+
+```bash
+[ -n "$WIKI_SCRIPT" ] && python3 "$WIKI_SCRIPT" ingest_paper research-wiki/ --arxiv-id "$id"
+```
+
+## Why four locations and not one
+
+Four locations correspond to four legitimate install / dev paths:
+
+| Location | When applicable |
+|---|---|
+| `.aris/tools/research_wiki.py` | After running `bash tools/install_aris.sh` in the user project (Phase 0 symlink, added in #174 / #192) |
+| `tools/research_wiki.py` | (a) Manual copy of the helper into the user project (a documented temporary workaround); (b) running a SKILL from inside the ARIS repo itself |
+| `$ARIS_REPO/tools/research_wiki.py` | Env var explicitly set, or auto-resolved from `.aris/installed-skills.txt`'s `repo_root` field |
+| `$ARIS_REPO/tools/research_wiki.py` via `~/.aris/repo` | Global pointer file written by `install_aris*.{sh,ps1}` / `smart_update*.{sh,ps1}` (#366); the only layer that resolves for a **global copy-install** (`~/.claude/skills/research-wiki`) where none of the first three apply — there is no project-local `.aris/`, no `tools/` copy, and no manifest to read `ARIS_REPO` from |
+
+Order matters: the symlinked install is preferred because the symlink
+auto-tracks upstream tool fixes; the manual copy is second because it
+catches users who haven't run `install_aris.sh`; the manifest-derived
+env var is next because a project-local manifest is more precise than
+a global pointer; the global pointer file is last because it is
+per-user rather than per-project and only fires when the first three
+all miss.
+
+## What NOT to add
+
+- ❌ A layer that searches up the directory tree for `tools/` — too
+  much path magic, surprising failure modes.
+- ❌ A layer at `/usr/local/share/...` or another OS-specific system
+  path — `~/.aris/repo` already covers the global-install gap with a
+  single per-user file, no OS branching needed.
+- ❌ Adding `~/.codex/skills/research-wiki/research_wiki.py` — that's
+  Codex-side global install, lives in the **Codex** mirror's chain
+  (`skills/skills-codex/...`), not the CC chain.
+
+`~/.aris/repo` (layer 4, #366) is the one exception to the earlier
+"no 4th layer" stance in this doc's history: it exists because the
+installer/updater now writes it, giving the previously-missing
+precedent. If a 5th layer is ever proposed, it should still meet the
+same bar — a concrete writer, not just a hopeful lookup — rather than
+an implicit env var or path-walk.
+
+## ⚠️ Do not wrap the chain in `set -e` / `set -eu`
+
+The `${ARIS_REPO:-$(awk ...)}` substitution propagates the inner
+`awk` exit code to `set -e` even when stderr is suppressed with
+`2>/dev/null`. `awk` returns non-zero (2 on most macOS systems) when
+its input file does not exist — which is the common case (no
+`.aris/installed-skills.txt` yet). With `set -e` enabled, the chain
+will exit silently with code 2 before reaching the `[ -f ... ]`
+checks, masking the real failure mode and breaking the manual-copy
+fallback.
+
+If a SKILL author wants strict-mode safety, restructure the manifest
+read instead:
+
+```bash
+if [ -z "${ARIS_REPO:-}" ] && [ -f .aris/installed-skills.txt ]; then
+    ARIS_REPO=$(awk -F'\t' '$1=="repo_root"{print $2; exit}' .aris/installed-skills.txt 2>/dev/null) || true
+fi
+```
+
+But the simpler answer is: don't enable strict mode for the resolver
+preamble. SKILL bash blocks do not run with `set -e` by default and
+the rest of the helper invocations all use explicit `[ -n "$WIKI_SCRIPT" ] && ...`
+guards anyway.
+
+## See also
+
+- [`integration-contract.md`](integration-contract.md) §2 — canonical-helper invariant
+- `skills/research-wiki/SKILL.md` — the wiki tool itself; uses Variant A
+- PR #193 — the parallel fix for `experiment-queue` helpers (same pattern, different helper)