dsh-aris-panel 0.1.0

package/skills/skills-codex/shared-references/review-tracing.md

@@ -0,0 +1,144 @@
+# Review Tracing Protocol
+
+## Purpose
+
+Save full prompt/response pairs for every reviewer call, enabling:
+
+- reviewer-independence audit
+- reproducibility across follow-up reviewer turns
+- meta-optimization from real review traces
+
+## When to Trace
+
+Trace every Codex reviewer call that serves a critique, scoring, claim-verification, experiment-audit, or patch-gating function.
+
+This includes:
+
+- `spawn_agent` reviewer calls
+- `send_input` reviewer continuations
+- optional overlay reviewer routes
+- adversarial reviewer calls used for stress tests
+
+Do not trace purely informational agent calls that are not acting as reviewers.
+
+## How to Trace
+
+After each reviewer call, save the trace using `save_trace.sh`,
+resolved through the canonical helper chain (see
+`integration-contract.md` §2 — failure policy C, "forensic helper").
+A Codex-side SKILL must NOT hard-code `tools/save_trace.sh`; instead
+it resolves `$TRACE_HELPER` via the chain and either invokes the
+helper or writes trace artifacts directly per the schemas below. If
+the resolver returns the empty string, write the four files inline
+— do not silently skip unless `--- trace: off` was requested.
+
+## Trace Directory
+
+```text
+.aris/traces/<skill-name>/<YYYY-MM-DD>_run<NN>/
+  run.meta.json
+  001-<purpose>.request.json
+  001-<purpose>.response.md
+  001-<purpose>.meta.json
+  002-<purpose>.request.json
+  ...
+```
+
+## File Schemas
+
+`run.meta.json`:
+
+```json
+{
+  "skill": "auto-review-loop",
+  "run_id": "2026-04-15_run01",
+  "started_at": "2026-04-15T14:30:00+08:00",
+  "executor": "codex",
+  "executor_model": "gpt-5.6-sol",
+  "executor_family": "openai",
+  "review_independence": "same-family",
+  "acceptance_status": "provisional",
+  "project_dir": "/path/to/project"
+}
+```
+
+`NNN-<purpose>.request.json`:
+
+```json
+{
+  "call_number": 1,
+  "purpose": "round-1-review",
+  "timestamp": "2026-04-15T14:31:00+08:00",
+  "tool": "spawn_agent",
+  "model": "gpt-5.6-sol",
+  "reasoning_effort": "xhigh",
+  "files_referenced": ["paper/sections/3_method.tex", "results/table1.csv"],
+  "prompt": "<full prompt text>"
+}
+```
+
+`NNN-<purpose>.response.md` stores the full reviewer response verbatim.
+
+`NNN-<purpose>.meta.json`:
+
+```json
+{
+  "call_number": 1,
+  "purpose": "round-1-review",
+  "timestamp": "2026-04-15T14:33:00+08:00",
+  "agent_id": "019d8fe0-b25d-...",
+  "model": "gpt-5.6-sol",
+  "reviewer_family": "openai",
+  "review_independence": "same-family",
+  "acceptance_status": "provisional",
+  "duration_ms": 142000,
+  "status": "ok"
+}
+```
+
+For a Claude/Gemini overlay write `review_independence: cross-family` and
+`acceptance_status: accepted`. For a deterministic verifier write
+`review_independence: deterministic` and `acceptance_status: accepted`. These
+fields describe the reviewer route; they do not rewrite the substantive verdict.
+
+## Configuration
+
+Respect inline parameter `--- trace: off | meta | full`:
+
+- `full` default: save full prompt and full response
+- `meta`: save metadata only
+- `off`: disable tracing
+
+## Events
+
+After writing a trace, append a compact event to `.aris/meta/events.jsonl`:
+
+```json
+{"event":"review_trace","skill":"auto-review-loop","purpose":"round-1-review","agent_id":"...","trace_path":".aris/traces/auto-review-loop/2026-04-15_run01/","status":"ok"}
+```
+
+## Debugging With Traces
+
+Traces are not only audit evidence — they are the **first place to look when a
+verdict is surprising**: a score regresses round-to-round, two reviewer agents
+disagree, or a claim check contradicts an earlier round. Before re-invoking the
+reviewer for "a better answer", read the raw transcript and find the moment its
+judgment actually changed:
+
+```bash
+skill=auto-review-loop run=2026-04-15_run01
+diff ".aris/traces/$skill/$run/002-round-2.response.md" \
+     ".aris/traces/$skill/$run/003-round-3.response.md"
+grep -En 'however|but|concern|missing|cannot' \
+     ".aris/traces/$skill/$run/003-round-3.response.md"
+```
+
+The paragraph where the assessment changed **is** the causal explanation for the
+divergence — cite it, don't guess. Re-running the reviewer without reading the
+trace is tuning by vibe: you get a new opinion, not an explanation. Same muscle
+as reading a stack trace before retrying a failed run — the trace is just
+written in English, and most of it is the reviewer talking to itself.
+
+## Privacy
+
+`.aris/traces/` is project-local and should not be committed. Use `--- trace: off` for strict confidentiality projects.

package/skills/skills-codex/shared-references/reviewer-independence.md

@@ -0,0 +1,66 @@
+# Reviewer Independence Protocol
+
+## Core Principle
+
+The reviewer must judge primary artifacts directly. The executor can define the review role, scope, and file list, but must not pre-digest the content into a preferred narrative.
+
+## What Can Be Passed
+
+- reviewer role or persona
+- review objective
+- absolute file paths
+- structural metadata such as section count or venue
+- concrete output schema
+
+## What Must Not Be Passed
+
+- executor summaries of file contents
+- executor interpretations of results
+- executor recommendations about what the reviewer should conclude
+- "what changed since last round" narratives unless the skill explicitly requires diff-focused follow-up
+- leading or coaching questions
+
+## Correct Pattern
+
+```text
+spawn_agent:
+  model: gpt-5.6-sol
+  reasoning_effort: xhigh
+  message: |
+    Review the project as a senior ML reviewer.
+
+    Files to read directly:
+    - /path/to/PROPOSAL.md
+    - /path/to/EXPERIMENT_LOG.md
+    - /path/to/paper/main.tex
+    - /path/to/src/
+```
+
+## Incorrect Pattern
+
+```text
+spawn_agent:
+  model: gpt-5.6-sol
+  reasoning_effort: xhigh
+  message: |
+    The main contribution is a new loss function that improves by 15%.
+    I think the weak point is the ablation.
+    Please confirm this is publishable.
+```
+
+## Multi-Round Follow-Up
+
+When a skill uses multi-round review, reuse the same reviewer id with `send_input`, but still avoid injecting executor conclusions. Pass revised artifacts or targeted follow-up requests, not spin.
+
+## Applies To
+
+This protocol applies to all cross-agent review calls in `skills/skills-codex/`, including:
+
+- `research-review`
+- `auto-review-loop`
+- `paper-plan`
+- `paper-write`
+- `paper-figure`
+- `rebuttal`
+- `meta-optimize`
+- any skill that launches a reviewer via `spawn_agent` or continues one via `send_input`

package/skills/skills-codex/shared-references/reviewer-routing.md

@@ -0,0 +1,128 @@
+# Reviewer Routing
+
+## Default Reviewer Contract
+
+All reviewer-heavy Codex base skills use the same default contract:
+
+- executor: current Codex main agent
+- reviewer: second Codex reviewer, model `gpt-5.6-sol` (GPT-5.6-Sol)
+- reasoning effort: **two tiers** (since 2026-07-10; `ultra`/`max` need codex-cli ≥ 0.144.1) —
+  **deep-audit** skills use `ultra` (`proof-checker`, `kill-argument` core threads, `research-review`,
+  `experiment-audit`, `paper-claim-audit`, `result-to-claim`, `meta-apply`); **every other**
+  reviewer call uses `xhigh` (multi-round loops and per-item fan-outs stay `xhigh` — a
+  follow-up `send_input` cannot change model/effort, and per-item `ultra` multiplies cost)
+- round 1: `spawn_agent`
+- follow-up rounds: `send_input`
+
+This is the base default for `skills/skills-codex/`. No ARIS `— effort:` level or unrelated parameter changes the tier (ARIS `— effort: max` ≠ `reasoning_effort: max` — pipeline workload vs reviewer reasoning are different axes).
+
+**Capability fallback (first spawn of each tier only):** if `spawn_agent` errors explicitly on the effort enum (older codex-cli — applies only to the deep tier's `ultra`; `xhigh` predates 0.144.1), retry `reasoning_effort: xhigh`; if it errors explicitly on the model being unknown/unavailable to this account, retry `model: gpt-5.5` + `xhigh`. NEVER downgrade on timeout / rate-limit / auth / transport / server / context-length errors (risk of double-running). Never run a verdict-bearing review below `xhigh`; if no allowed pair works, report `REVIEW_UNAVAILABLE` — never substitute the executor's own judgment.
+
+> ⚠️ **Same-family by default — provisional, never accepted.** The executor here
+> is Codex (GPT family) and the reviewer is a fresh Codex agent from the same
+> family. Its substantive PASS/WARN/FAIL may drive revisions, terminate a loop,
+> and advance a resumable phase, but every positive result records:
+>
+> ```yaml
+> review_independence: same-family
+> acceptance_status: provisional
+> ```
+>
+> It must never be described as cross-model acceptance. Install the
+> **`skills-codex-claude-review`** or **`skills-codex-gemini-review`** overlay
+> for `review_independence: cross-family` and `acceptance_status: accepted`.
+> A deterministic verifier may also record accepted. `oracle-pro` is GPT family,
+> so it remains provisional for a Codex executor.
+
+## Default Pattern
+
+Single-round review:
+
+```text
+spawn_agent:
+  model: gpt-5.6-sol
+  reasoning_effort: xhigh   # deep-audit skills: ultra (see tier table above)
+  message: |
+    [role + task]
+    Read the listed files directly.
+```
+
+Multi-round review:
+
+```text
+spawn_agent:
+  model: gpt-5.6-sol
+  reasoning_effort: xhigh   # deep-audit skills: ultra (see tier table above)
+  message: |
+    [initial review prompt]
+```
+
+Save the returned reviewer id, then continue with:
+
+```text
+send_input:
+  target: <saved reviewer id>
+  message: |
+    [follow-up materials only]
+```
+
+## Oracle Pro Override
+
+When the user explicitly passes `--reviewer: oracle-pro`, switch only the reviewer route:
+
+- default reviewer remains Codex at the call's declared tier (deep-audit: ultra / regular: xhigh) if no reviewer is specified
+- `oracle-pro` is optional, not the base default
+
+Routing rule:
+
+```text
+If reviewer is omitted or reviewer=codex:
+  use spawn_agent / send_input with the Codex reviewer at the call's declared tier
+
+If reviewer=oracle-pro:
+  check Oracle MCP availability
+  if available:
+    call mcp__oracle__consult with model gpt-5.5-pro
+  if unavailable:
+    print a clear warning
+    fall back to the default Codex reviewer at the call's declared tier
+```
+
+## Invariants
+
+- Base skills do not use the legacy Codex MCP thread path as the default reviewer route.
+- Reviewer independence still applies: pass file paths and task framing, not executor summaries.
+- Overlay packages may replace only the reviewer route.
+- Overlay packages do not change executor semantics.
+- Every trace and audit artifact records `review_independence` and
+  `acceptance_status`; missing metadata is treated as provisional.
+- If `spawn_agent` is unavailable or fails, emit `BLOCKED` /
+  `REVIEW_UNAVAILABLE`; never fabricate a provisional PASS.
+- Do not wrap verdict-bearing skills in `/loop`, cron, or wall-clock retries.
+  Schedule only external-world waits, then invoke the reviewer once after the
+  artifact changes. See `external-cadence.md`.
+- Browser-based Oracle review is acceptable for one-shot stress tests, not ideal for tight multi-round loops.
+
+## Copilot CLI reviewer behavior in the main skill set
+
+The main `skills/shared-references/reviewer-routing.md` defaults
+`/auto-review-loop` to Copilot CLI's native complementary `rubber-duck`
+subagent when a host-session marker binds. Its stop gate requires revalidated
+native lifecycle/model/response evidence and a known cross-family pair. The
+older `--reviewer: copilot` custom-agent subprocess remains an explicit
+compatibility drive mode and still needs a Codex/manual finalizer.
+
+**This routing applies to the main skills at `skills/`, not this Codex-mirror
+pack.** Here `spawn_agent` remains the native reviewer. See the main
+[`reviewer-routing.md`](../../../skills/shared-references/reviewer-routing.md#copilot-cli-native-rubber-duck-default-for-auto-review-loop)
+for the Copilot contract.
+
+## Skills That Commonly Benefit From `oracle-pro`
+
+- `research-review`
+- `auto-review-loop`
+- `experiment-audit`
+- `proof-checker`
+- `rebuttal`
+- `idea-creator`
+- `research-lit`

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

@@ -0,0 +1,119 @@
+# Skill Governance: Provenance-as-Authorization
+
+> **Codex mirror adaptation (normative).** A Codex-authored change reviewed by a
+> fresh Codex agent uses `provenance.py stamp-provisional`. The receipt preserves
+> author/reviewer family, verdict id and content hash but does not make the
+> artifact auto-curatable. Cross-family overlays or deterministic verifiers use
+> strict `stamp` and may grant accepted 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_curatable(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_curatable` 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.5`+`codex`,
+  or the trap `gpt-5.5`+`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 provisional receipt may be same-family but grants no authorization.**
+  `stamp_provisional()` requires the author/reviewer families to match and writes
+  `review_independence: same-family`, `acceptance_status: provisional`.
+  `is_auto_authored()` remains true as an identity fact, while
+  `is_auto_curatable()` is false. This is the Codex-only review path.
+
+- **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
+
+Strict `stamp(target, author_model, reviewer_model, verdict_id)` writes accepted
+authorization; `stamp_provisional(...)` writes the same receipt shape with
+provisional review metadata.
+
+```json
+{
+  "created_by": "aris-auto",
+  "author_model": "claude-opus-4-8",
+  "author_family": "anthropic",
+  "reviewer_model": "gpt-5.5",
+  "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 an accepted re-stamp (= a fresh
+  cross-family or deterministic 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/skills-codex/shared-references/taste-calibration.md

@@ -0,0 +1,90 @@
+# Taste Calibration Protocol
+
+> **Codex mirror adaptation (normative).** The weighted axes, human-curated
+> anchors and GAP output contract are unchanged. A calibrated score from a fresh
+> Codex reviewer may drive revisions and yield a provisional result; it is not
+> cross-family acceptance unless an overlay supplies the reviewer.
+
+> 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/skills-codex/shared-references/venue-checklists.md

@@ -0,0 +1,73 @@
+# Venue Checklists for ICLR, NeurIPS, and ICML
+
+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.
+
+## 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.