dsh-aris-panel 0.1.0

package/skills/skills-codex/figure-spec/SKILL.md

@@ -0,0 +1,252 @@
+---
+name: figure-spec
+description: "Generate deterministic publication-quality architecture, workflow, and pipeline diagrams from structured JSON (FigureSpec) into editable SVG. Use when user says \"架构图\", \"workflow 图\", \"pipeline 图\", \"确定性矢量图\", \"figure spec\", \"draw architecture\", or needs precise, editable, publication-ready vector diagrams. Preferred over AI illustration for formal architecture/workflow figures."
+argument-hint: "[description-of-diagram]"
+allowed-tools: Bash(*), Read, Write, Edit
+---
+
+# FigureSpec: Deterministic JSON → SVG Figure Generation
+
+Generate publication-quality **architecture diagrams**, **workflow pipelines**, **audit cascades**, and **system topology** figures as editable SVG vector graphics using a deterministic JSON → SVG renderer.
+
+## When to Use This Skill
+
+**Use `figure-spec`** for:
+- System architecture diagrams (layered, hub-and-spoke, multi-plane)
+- Workflow / pipeline figures
+- Audit cascade / flow-control diagrams
+- Any structured diagram where node positions, connections, and groupings are semantically important
+- Figures that need to be edited/tweaked later (SVG is plain text)
+- Figures where determinism matters (same spec → same SVG)
+
+**Do NOT use for:**
+- Data plots (bar/line/scatter) — use `/paper-figure`
+- Natural/qualitative illustrations — use `/paper-illustration`
+- Quick state-machine / flowchart — use `/mermaid-diagram` (lighter syntax)
+
+## Core Properties
+
+- **Deterministic**: identical FigureSpec JSON always produces identical SVG output (for a fixed renderer version + fonts)
+- **Editable**: SVG output is plain-text, can be post-edited by hand or programmatically
+- **Validated**: renderer enforces schema, rejects malformed specs with clear error messages
+- **Shape-aware**: edge clipping works correctly for rect/rounded/circle/ellipse/diamond
+- **CJK support**: multi-line labels with proper Chinese character width estimation
+- **No external API**: runs fully local, no network, no API keys
+
+## Tool Location
+
+Phase 3.1 (Arch C) move: the canonical implementation now lives at
+`skills/figure-spec/scripts/figure_renderer.py`. `tools/figure_renderer.py`
+is kept as a backwards-compatible `os.execv` shim so legacy layers
+continue to resolve. Codex-side install layouts that previously
+copied the canonical into `~/.codex/skills/figure-spec/figure_renderer.py`
+must now place it at `~/.codex/skills/figure-spec/scripts/figure_renderer.py`
+to match the new layout (re-run `install_aris_codex.sh` to pick up
+the new symlink target).
+
+Resolve `$FIGURE_RENDERER` via the Codex-side hybrid chain (layer 0
+preferred for self-contained owner SKILL; layers 1-4 are legacy
+shared-runtime compatibility):
+
+```bash
+# Layer 0: self-contained at the new canonical location (Phase 3.1).
+FIGURE_RENDERER=""
+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
+[ -n "${ARIS_REPO:-}" ] && [ -f "$ARIS_REPO/skills/figure-spec/scripts/figure_renderer.py" ] && FIGURE_RENDERER="$ARIS_REPO/skills/figure-spec/scripts/figure_renderer.py"
+
+# Layers 1-3: legacy shared-runtime chain via shim at tools/figure_renderer.py.
+[ -z "$FIGURE_RENDERER" ] && [ -n "${ARIS_REPO:-}" ] && [ -f "$ARIS_REPO/tools/figure_renderer.py" ] && FIGURE_RENDERER="$ARIS_REPO/tools/figure_renderer.py"
+[ -z "$FIGURE_RENDERER" ] && [ -f tools/figure_renderer.py ] && FIGURE_RENDERER="tools/figure_renderer.py"
+
+# Layer 4: Codex-side skill-local install (`install_aris_codex.sh` may place it here).
+[ -z "$FIGURE_RENDERER" ] && [ -f ~/.codex/skills/figure-spec/scripts/figure_renderer.py ] && FIGURE_RENDERER="$HOME/.codex/skills/figure-spec/scripts/figure_renderer.py"
+[ -z "$FIGURE_RENDERER" ] && [ -f ~/.codex/skills/figure-spec/figure_renderer.py ] && FIGURE_RENDERER="$HOME/.codex/skills/figure-spec/figure_renderer.py"  # pre-Phase-3.1 layout
+
+[ -n "$FIGURE_RENDERER" ] || {
+  echo "ERROR: figure_renderer.py not found at any of: \$ARIS_REPO/skills/figure-spec/scripts/, \$ARIS_REPO/tools/, tools/, ~/.codex/skills/figure-spec/scripts/, ~/.codex/skills/figure-spec/. Set ARIS_REPO, rerun install_aris_codex.sh, or copy the canonical \$ARIS_REPO/skills/figure-spec/scripts/figure_renderer.py next to this skill." >&2
+  exit 1
+}
+
+python3 "$FIGURE_RENDERER" render <spec.json> --output <out.svg>
+python3 "$FIGURE_RENDERER" validate <spec.json>
+python3 "$FIGURE_RENDERER" schema
+```
+
+## Workflow
+
+### Step 1: Understand the Diagram Goal
+
+From `$ARGUMENTS` (description or path to `PAPER_PLAN.md` / `NARRATIVE_REPORT.md`), identify:
+- **Purpose**: architecture, workflow, pipeline, audit cascade, topology?
+- **Main entities**: what are the boxes?
+- **Relationships**: how do they connect? (uses, produces, calls, verifies, chains)
+- **Grouping**: do entities cluster into named regions?
+- **Hierarchy vs network**: stacked layers, left-to-right flow, or central hub?
+
+### Step 2: Draft the FigureSpec JSON
+
+Canvas sizing guide:
+- Single-column figure: ~500×350 px
+- Two-column (full-width): ~900×500 px
+- Tall topology: ~700×700 px
+
+Start from a template based on the diagram type:
+
+**Architecture (stacked rows)**:
+```json
+{
+  "canvas": {"width": 900, "height": 520},
+  "nodes": [
+    {"id": "layer1_label", "label": "Layer 1", "x": 450, "y": 60, ...},
+    {"id": "node_a", "label": "A", "x": 180, "y": 120, ...},
+    {"id": "node_b", "label": "B", "x": 350, "y": 120, ...}
+  ],
+  "edges": [...],
+  "groups": [
+    {"label": "Layer 1", "node_ids": ["node_a", "node_b"], "fill": "#F0F9FF", "stroke": "#BAE6FD"}
+  ]
+}
+```
+
+**Workflow (left-to-right chain)**:
+```json
+{
+  "canvas": {"width": 900, "height": 300},
+  "nodes": [
+    {"id": "step1", "label": "Step 1", "x": 100, "y": 150, "shape": "rounded"},
+    {"id": "step2", "label": "Step 2", "x": 280, "y": 150, "shape": "rounded"}
+  ],
+  "edges": [
+    {"from": "step1", "to": "step2", "label": "produces"}
+  ]
+}
+```
+
+**Decision diamond**:
+```json
+{"id": "check", "label": "Passes?", "shape": "diamond", "x": 450, "y": 200}
+```
+
+### Step 3: Render and Validate
+
+```bash
+# Validate first
+python3 "$FIGURE_RENDERER" validate /tmp/spec.json
+
+# Render to SVG
+python3 "$FIGURE_RENDERER" render /tmp/spec.json --output figures/fig_arch.svg
+
+# Convert to PDF for LaTeX inclusion
+rsvg-convert -f pdf figures/fig_arch.svg -o figures/fig_arch.pdf
+```
+
+If validation fails, inspect the error (missing field, duplicate ID, overlap warning, invalid hex color) and fix the JSON.
+
+### Step 4: Visual Review
+
+Open the SVG/PDF and check:
+- **No overlaps**: nodes don't collide with each other or group boundaries
+- **Readability**: font sizes are consistent, labels aren't clipped
+- **Edge clarity**: arrows hit nodes at clean angles, labels near edges are legible
+- **Group alignment**: background rectangles frame their members cleanly
+- **Color distinction**: categories are visually distinct in both color and grayscale
+
+If issues found, edit the JSON spec (never the generated SVG) and re-render.
+
+### Step 5: Iterate with Codex Review (Optional, for High-Stakes Figures)
+
+For paper architecture figures, invoke fresh-agent review (same-family provisional in the base mirror):
+
+```text
+spawn_agent:
+  model: gpt-5.6-sol
+  reasoning_effort: xhigh
+  message: |
+    Review this SVG figure for a technical paper (architecture / workflow diagram).
+
+    Spec file: /path/to/spec.json
+    Rendered: /path/to/fig.svg
+
+    Evaluate:
+    1. Clarity (C): can a reader understand the system from this figure alone?
+    2. Readability (R): font sizes, label placement, visual hierarchy
+    3. Semantic accuracy (S): do relationships match the described system?
+
+    Score each axis 1-10 and list specific issues to fix.
+```
+
+Iterate until all three axes ≥ 7/10. The ARIS tech report figures went through 5 rounds of this loop to reach C:7/R:7/S:8.
+
+## Schema Quick Reference
+
+Run `python3 "$FIGURE_RENDERER" schema` for the authoritative schema.
+
+### Nodes
+
+| Field | Required | Default | Notes |
+|-------|----------|---------|-------|
+| `id` | ✓ | — | Unique |
+| `label` | ✓ | — | `\n` for multi-line |
+| `x`, `y` | ✓ | — | Center coordinates |
+| `width`, `height` | | 120, 50 | |
+| `shape` | | `rounded` | `rect` / `rounded` / `circle` / `ellipse` / `diamond` |
+| `fill`, `stroke` | | auto from palette | `#RRGGBB` |
+| `text_color` | | `#333333` | |
+| `font_size` | | 14 | Override style default |
+
+### Edges
+
+| Field | Default | Notes |
+|-------|---------|-------|
+| `from`, `to` | required | Same = self-loop |
+| `label` | — | Short edge label |
+| `style` | `solid` | `solid` / `dashed` / `dotted` |
+| `color` | `#555555` | |
+| `curve` | `false` | Curved path |
+
+### Groups
+
+Rectangular background regions framing a set of nodes:
+```json
+{"label": "Layer Name", "node_ids": ["a", "b", "c"], "fill": "#EFF6FF", "stroke": "#BFDBFE"}
+```
+
+## Design Patterns
+
+### Pattern 1: Layered Architecture
+Stack rows of related nodes, each row is a group, add inter-layer arrows with semantic labels (`uses↓`, `produces↑`, `checks↓`).
+
+### Pattern 2: Hub-and-Spoke
+Central node (e.g., Executor), peripheral nodes (skills, tools), solid arrows for primary relations, dashed for feedback.
+
+### Pattern 3: Pipeline with Feedback
+Left-to-right main flow, feedback arrows curve below with `curve: true`.
+
+### Pattern 4: Audit Cascade
+Three-stage horizontal cascade with inputs feeding in from top, outputs exiting right, each stage in its own group.
+
+## Anti-Patterns
+
+- **Don't use groups as hierarchy**: groups frame peer nodes, not containment
+- **Don't nest groups**: renderer draws them as background rectangles; nested groups look like Russian dolls
+- **Don't cross-draw long diagonals**: if an arrow crosses 3+ rows, rethink the layout
+- **Don't mix font sizes for same role**: keep one size per node category
+
+## Output Contract
+
+- SVG file in `figures/` (vector, editable, hand-tweakable)
+- Source FigureSpec JSON saved in `figures/specs/` for reproducibility
+- PDF version via `rsvg-convert` for LaTeX inclusion
+
+## Integration with Other Skills
+
+- **`/paper-writing`** (Workflow 3): when `illustration: figurespec` (default for architecture figures), this skill handles Phase 2b
+- **`/paper-figure`**: handles data plots; they complement each other (data + architecture = complete figure set)
+- **`/paper-illustration`**: fallback for figures that need natural/qualitative style (method illustrations with photos, qualitative result grids)
+- **`/mermaid-diagram`**: lighter alternative for simple flowcharts
+
+## 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`).

package/skills/skills-codex/formula-derivation/SKILL.md

@@ -0,0 +1,280 @@
+---
+name: formula-derivation
+description: Structures and derives research formulas when the user wants to 推导公式, build a theory line, organize assumptions, turn scattered equations into a coherent derivation, or rewrite theory notes into a paper-ready formula document. Use when the derivation target is not yet fully fixed, the main object still needs to be chosen, or the user needs a coherent derivation package rather than a finished theorem proof.
+argument-hint: "[problem-goal-current-formulas-or-notes]"
+allowed-tools: Read, Write, Edit, Grep, Glob
+---
+
+# Formula Derivation: Research Theory Line Construction
+
+Build an honest derivation package, not a fake polished theorem story.
+
+## Constants
+
+- DEFAULT_DERIVATION_DOC = `DERIVATION_PACKAGE.md` in project root
+- STATUS = `COHERENT AS STATED | COHERENT AFTER REFRAMING / EXTRA ASSUMPTION | NOT YET COHERENT`
+
+## Context: $ARGUMENTS
+
+## Goal
+
+Produce exactly one of:
+1. a coherent derivation package for the original target
+2. a reframed derivation package with corrected object / assumptions / scope
+3. a blocker report explaining why the current notes cannot yet support a coherent derivation
+
+## Inputs
+
+Extract and normalize:
+- the target phenomenon, formula, relation, or theory line
+- the intended role of the derivation:
+  - exact identity / algebra
+  - proposition / local theorem
+  - approximation
+  - mechanism interpretation
+- explicit assumptions
+- notation and definitions
+- any user-provided formula chain, sketch, messy notes, or current draft
+- nearby local theory files if the request points to them
+- desired output style if specified:
+  - internal alignment note
+  - paper-style theory draft
+  - blocker report
+
+If the target, object, notation, or assumptions are ambiguous, state the exact interpretation you are using before deriving anything.
+
+## Workflow
+
+### Step 1: Gather Derivation Context
+Determine the target derivation file with this priority:
+1. a file path explicitly specified by the user
+2. a derivation draft already referenced in local notes
+3. `DERIVATION_PACKAGE.md` in project root as the default target
+
+Read the relevant local context:
+- the chosen target derivation file, if it already exists
+- any local theory notes, formula drafts, appendix notes, or files explicitly mentioned by the user
+
+Extract:
+- target formula / theory goal
+- current formula chain
+- assumptions
+- notation
+- known blockers
+- desired output mode
+
+### Step 2: Freeze the Target
+State explicitly:
+- what is being explained, derived, or supported
+- whether the immediate goal is:
+  - identity / algebra
+  - proposition
+  - approximation
+  - interpretation
+- what the derivation is expected to output in the end
+
+Do not start symbolic manipulation before this is fixed.
+
+### Step 3: Choose the Invariant Object
+Identify the single quantity or conceptual object that should organize the derivation.
+
+Typical possibilities include:
+- objective / utility / loss
+- total cost / energy / welfare
+- conserved quantity / state variable
+- expected metric / effective rate / effective cost
+
+If the current notes start from a narrower quantity, decide explicitly whether it is:
+- the true top-level object
+- a proxy
+- a local slice
+- an approximation
+
+Do not let a convenient proxy silently replace the actual conceptual object.
+
+### Step 4: Normalize Assumptions and Notation
+Restate:
+- all assumptions
+- all symbols
+- regime boundaries or special cases
+- which quantities are fixed, adaptive, or state dependent
+
+Identify:
+- hidden assumptions
+- undefined notation
+- scope ambiguities
+- whether the current formula chain already mixes exact steps with approximations
+
+Preserve the user's original notation unless a cleanup is necessary for coherence.
+If you adopt a cleaner internal formulation, keep that as a derivation device rather than silently replacing the user's target.
+
+### Step 5: Classify the Derivation Steps
+For every nontrivial step, determine whether it is:
+- **identity**: exact algebraic reformulation
+- **proposition**: a claim requiring conditions
+- **approximation**: model simplification or surrogate
+- **interpretation**: prose-level meaning of a formula
+
+Never merge these categories without signaling the transition.
+If one part is only interpretive, do not present it as if it were mathematically proved.
+
+### Step 6: Build a Derivation Map
+Choose a derivation strategy, for example:
+- definition -> substitution -> simplification
+- primitive law -> intermediate variable -> target expression
+- global quantity -> perturbation -> decomposition
+- exact model -> approximation -> interpretable closed form
+- general dynamic object -> simplified slice -> local theorem -> return to general case
+
+Then write a derivation map:
+- target formula or theory line
+- required intermediate identities or lemmas
+- which assumptions each nontrivial step uses
+- where approximations enter
+- where special-case and general-case regimes diverge or collapse
+
+If the derivation needs a decomposition, derive it from the chosen global quantity.
+Do not make a split appear magically from one local variable itself.
+
+### Step 7: Write the Derivation Document
+Write to the chosen target derivation file.
+
+If the target derivation file already exists:
+- read it first
+- update the relevant section
+- do not blindly duplicate prior content
+
+If the user does not specify a target, default to `DERIVATION_PACKAGE.md` in project root.
+
+Do NOT write directly into paper sections or appendix `.tex` files unless the user explicitly asks for that target.
+
+The derivation package must include:
+- target
+- status
+- invariant object
+- assumptions
+- notation
+- derivation strategy
+- derivation map
+- main derivation steps
+- remarks / interpretations
+- boundaries and non-claims
+
+Writing rules:
+- do not hide gaps with words like "clearly", "obviously", or "similarly"
+- define every symbol before use
+- mark approximations explicitly
+- separate derivation body from remarks
+- if the true object is dynamic or state dependent but a simpler slice is analyzed, say so explicitly
+- if a formula line is only heuristic, label it honestly
+
+### Step 8: Final Verification
+Before finishing the target derivation file, verify:
+- the target is explicit
+- the invariant object is stable across the derivation
+- every assumption used is stated
+- each formula step is correctly labeled as identity / proposition / approximation / interpretation
+- the derivation does not silently switch objects
+- special cases and general cases still belong to one theory line
+- boundaries and non-claims are stated
+
+If the derivation still lacks a coherent object, stable assumptions, or an honest path from premises to result, downgrade the status and write a blocker report instead of forcing a clean story.
+
+## Required File Structure
+
+Write the target derivation file using this structure:
+
+```md
+# Derivation Package
+
+## Target
+[what is being derived or explained]
+
+## Status
+COHERENT AS STATED / COHERENT AFTER REFRAMING / NOT YET COHERENT
+
+## Invariant Object
+[top-level quantity organizing the derivation]
+
+## Assumptions
+- ...
+
+## Notation
+- ...
+
+## Derivation Strategy
+[chosen route and why]
+
+## Derivation Map
+1. Target depends on ...
+2. Intermediate step A uses ...
+3. Approximation enters at ...
+
+## Main Derivation
+Step 1. ...
+Step 2. ...
+...
+
+## Remarks and Interpretation
+- ...
+
+## Boundaries and Non-Claims
+- ...
+
+## Open Risks
+- ...
+```
+
+## Output Modes
+
+### If the derivation is coherent as stated
+Write the full structure above with a clean derivation package.
+
+### If the notes are close but not coherent yet
+Write:
+- the exact mismatch
+- the corrected invariant object, assumption, or scope
+- the reframed derivation package
+
+### If the derivation cannot be made coherent honestly
+Write:
+- `Status: NOT YET COHERENT`
+- the exact blocker:
+  - missing object
+  - unstable assumptions
+  - notation conflict
+  - unsupported approximation
+  - theorem-level claim without enough conditions
+- what extra assumption, reframe, or intermediate derivation would be needed
+
+## Relationship to `proof-writer`
+
+Use `formula-derivation` when the user says things like:
+- “我不知道怎么起这条推导主线”
+- “这个公式到底该从哪个量出发”
+- “帮我把理论搭顺”
+- “把说明文档变成可写进论文的公式文档”
+- “这几段公式之间逻辑不通”
+
+Use `proof-writer` only after:
+- the exact claim is fixed
+- the assumptions are stable
+- the notation is settled
+- and the task is now to prove or refute that claim rigorously
+
+## Chat Response
+
+After writing the target derivation file, respond briefly with:
+- status
+- whether the target survived unchanged or had to be reframed
+- what file was updated
+
+## Key Rules
+
+- Never fabricate a coherent derivation if the object, assumptions, or scope do not support one.
+- Prefer reframing the derivation over overclaiming.
+- Separate assumptions, identities, propositions, approximations, and interpretations.
+- Keep one invariant object across special and general cases whenever possible.
+- Treat simplified constant-parameter cases as analysis slices, not as the conceptual main object.
+- If uncertainty remains, mark it explicitly in `Open Risks`; do not hide it in polished prose.
+- Coherence matters more than elegance.