create-yss-spec 2.1.4 → 2.1.6

package/template/.codex/skills/drawio-academic-skills/references/docs/academic-figure-playbook.md

@@ -1,349 +0,0 @@
-# Academic Figure Playbook
-
-Use this playbook whenever `meta.profile = academic-paper` or the user asks for a paper, thesis, journal, IEEE, manuscript, or research figure.
-
-## Step 1: Classify the Figure
-
-Before drafting nodes, answer one question:
-
-What is this figure mainly explaining?
-
-- **Structure** -> `meta.figureType: architecture`
-- **Progression** -> `meta.figureType: roadmap`
-- **Execution** -> `meta.figureType: workflow`
-
-If the answer is mixed, pick the dominant purpose. If the diagram tries to explain structure, progression, and branching control logic at the same time, split it into two figures.
-
-## Figure Types
-
-### Architecture
-
-Use for:
-
-- system composition
-- module boundaries
-- data movement between tiers
-- runtime responsibilities
-- model architectures such as CNN, YOLO, Transformer, encoder-decoder, feature fusion, or multi-head prediction
-
-Quality cues:
-
-- group subsystems clearly
-- emphasize layers or boundaries
-- avoid turning the diagram into a chronological pipeline
-- use modules for stages and semantic node types for layers, tensors, operators, and outputs
-- keep layer labels compact; move tensor sizes, assumptions, or metrics into callouts or legends when needed
-
-### Roadmap
-
-Use for:
-
-- study phases
-- milestone progression
-- delivery stages
-- stage outputs
-
-Quality cues:
-
-- make progression directional
-- show only major stages
-- surface the output or decision at the end of each stage
-
-### Workflow
-
-Use for:
-
-- ordered steps
-- decisions and branching
-- loops and fallback paths
-- procedural execution
-- method pipelines, ablation studies, experiment procedures, and validation loops
-
-Quality cues:
-
-- keep the step order obvious
-- label ambiguous decisions
-- keep back-edges and loops sparse and readable
-
-## Scientific Figure Patterns
-
-Worked examples under `references/examples/` (render via the sibling base CLI):
-
-- `yolo-model-architecture-paper.yaml` — model-architecture pattern (YOLO backbone/neck/head).
-- `max-pooling-operation-paper.yaml` — operation/mechanism pattern (max-pooling grid with explicit bounds).
-- `ablation-study-pipeline.yaml` — experiment-pipeline pattern (ablation variants over shared evaluation).
-- `research-pipeline.yaml` — experiment-pipeline pattern (end-to-end research workflow).
-- `system-architecture-paper.yaml` — architecture figure type (paper system overview).
-- `industrial-architecture-cn-paper.yaml` — architecture figure type (Chinese-thesis industrial system).
-- `ieee-network-paper.yaml` — architecture figure type with network stencils (IEEE style).
-- `technical-roadmap-paper.yaml` — roadmap figure type (milestone phases).
-
-### Model Architecture
-
-Use this pattern for CNN, YOLO, Transformer, encoder-decoder, and feature-fusion figures.
-
-- Set `meta.figureType: architecture`.
-- Use 3-5 modules for major stages such as Input, Backbone, Fusion/Neck, Prediction Head, Loss, or Output.
-- Prefer semantic types: `input`, `tensor3d`, `conv`, `pool`, `attention`, `feature`, `operator`, `loss`, and `output`.
-- Keep tensors and operators visually small. Use a legend for repeated layer notation instead of repeating long descriptions in every box.
-- Show only the architectural relationships needed for the paper argument; detailed implementation hyperparameters belong in the caption or body text.
-
-### Operation Or Mechanism
-
-Use this pattern for max pooling, attention scoring, gating, residual add, normalization, or algorithm-step illustrations.
-
-- Pick `workflow` when the figure explains an ordered operation, and `architecture` when it explains a static mechanism inside a model.
-- Use explicit `bounds` for small grids, matrices, formula boxes, callouts, and operator nodes.
-- Use native rectangles/text cells for grids or matrices. Do not use a screenshot of the operation as the final draw.io page.
-- Keep formulas short and use supported math delimiters from `math-typesetting.md`.
-- Offset arrows and edge labels with `labelOffset` so labels do not sit on connector lines.
-
-### Experiment Pipeline
-
-Use this pattern for datasets, treatments, ablations, simulations, or evaluation workflows.
-
-- Set `meta.figureType: workflow`.
-- Separate setup/data, variants or methods, shared evaluation, metrics, and reporting.
-- Draw ablation branches in parallel and converge them before validation or metrics.
-- Label branches with short method names. Use the legend for line styles, color encodings, or metric abbreviations.
-
-### Reference-Image Redraw
-
-Use this pattern when a paper screenshot or existing figure must become editable.
-
-- Use `meta.source: replicated`.
-- Preserve captions, legends, formulas, callouts, section headers, and connector labels as first-class elements.
-- Use `meta.canvas: WIDTHxHEIGHT` and top-left `bounds` when matching the source coordinate system matters.
-- Rebuild the main diagram with native draw.io cells and verify the exported SVG or Desktop artifact before any browser screenshot.
-
-## Visual Defaults
-
-- prefer white or very light backgrounds
-- use low-saturation colors unless the user explicitly wants a color paper figure
-- keep one dominant reading direction
-- align nodes to the grid instead of hand-placing them loosely
-- shorten labels before shrinking fonts
-- use consistent line weights, arrowheads, and corner radii
-- keep text, callouts, captions, and legends transparent (`fillColor=none`, `labelBackgroundColor=none`) and sized just wider than their content, not stretched to a container — see `../drawio/references/docs/design-system/tokens.md` § Text & Label Styling
-
-## Venue Palette Mapping
-
-After determining the venue, choose `meta.palette` independently from the theme. If the user did not specify a palette, ask once with `AskUserQuestion`: put the venue recommendation first with `(Recommended)`, offer 3-4 options, use each palette's display name as the label, and state colorblind/grayscale safety in the description. If the user named an unambiguous palette or style, apply it directly and do not ask.
-
-| Venue or scenario             | Recommended  | Alternatives                                              |
-| ----------------------------- | ------------ | --------------------------------------------------------- |
-| IEEE print / camera-ready     | `ieee-bw`    | `tol-high-contrast`, `ieee-color`                         |
-| IEEE online / conference      | `ieee-color` | `matlab-lines`, `okabe-ito`                               |
-| Elsevier / general journal    | `okabe-ito`  | `tol-bright`, `tol-muted`, `seaborn-colorblind`           |
-| Nature / Science family       | `okabe-ito`  | `tol-muted`, `journal-npg` (aesthetic only; not CVD-safe) |
-| Chinese thesis (`cn-thesis`)  | `ieee-bw`    | `tol-high-contrast`, `journal-jama`                       |
-| Engineering architecture / C4 | `c4-blue`    | `cloud-aws`, `drawio-classic`                             |
-| Cloud architecture            | `cloud-aws`  | `c4-blue`                                                 |
-
-For replication, preserve the source palette and skip this question unless the user explicitly asks to normalize or recolor the figure.
-
-## Academic Delivery Matrix
-
-Default output for paper-mode requests:
-
-- `.drawio`
-- `.svg`
-
-Keep reproducibility sidecars in the work directory by default, not in the final delivery directory:
-
-- `.spec.yaml`
-- `.arch.json`
-
-Add `.png` only when one of these is true:
-
-- the request is thesis or A4 focused
-- the figure is for Word or another raster-first workflow
-- the task is a screenshot or image rebuild that needs a matching raster companion
-- the user explicitly asks for PNG
-
-If draw.io Desktop export is unavailable, keep the offline bundle plus SVG as the completed baseline and note that PNG is optional follow-up.
-
-## Node Budget Management
-
-Academic figures should be clear and focused. Keep node count under 40 for optimal readability.
-
-### Budget Guidelines
-
-**Recommended targets by figure type**:
-
-| Figure Type  | Target Nodes | Maximum Nodes | Typical Distribution                     |
-| ------------ | ------------ | ------------- | ---------------------------------------- |
-| Architecture | 30-35        | 60            | 4-6 modules × 5-7 nodes + legend (1-2)   |
-| Workflow     | 25-30        | 50            | 15-20 steps + 5-8 decisions + legend (1) |
-| Roadmap      | 15-20        | 40            | 10-15 stages + 3-5 outputs + legend (1)  |
-
-**System warnings**:
-
-- 0-40 nodes: no warning (ideal range)
-- 41-60 nodes: warning (conversion succeeds, but consider simplification)
-- 61-100 nodes: error (blocked in strict mode, split strongly recommended)
-- > 100 nodes: fatal (always blocked, hard limit)
-
-### Node-Efficient Patterns
-
-Ready-made compact templates live under `references/templates/`: `multi-module-system-compact.yaml` (multi-module system inside the recommended budget) and `neural-network-architecture-compact.yaml` (neural-network architecture inside the recommended budget). Start from these before authoring node-heavy figures from scratch.
-
-#### Example 1: Legend
-
-**❌ Expanded Legend (wastes 12 nodes)**:
-
-```yaml
-- id: legend_container
-  label: "Legend"
-  bounds: { x: 1000, y: 400, width: 200, height: 160 }
-  style: { fillColor: "#FAFAFA" }
-
-- id: legend_arrow_solid
-  label: ""
-  bounds: { x: 1010, y: 430, width: 40, height: 2 }
-  style: { strokeColor: "#1E3A5F", strokeWidth: 2 }
-
-- id: legend_arrow_label
-  type: text
-  label: "Data flow"
-  bounds: { x: 1060, y: 426, width: 120, height: 16 }
-  style: { fontSize: 11 }
-# ... 10 more nodes for each legend item
-```
-
-**✅ Compact Legend (1 node)**:
-
-```yaml
-- id: legend
-  type: text
-  label: |
-    Legend
-
-    → Data flow
-    ⇢ Conditional flow
-    ⊙ Hadamard product
-    ∥ Concatenation
-
-    ■ Zone A: Feature extraction
-    ■ Zone B: Conditional embedding
-  style:
-    align: left
-  # no bounds/fontSize: the converter sizes the box and applies the 16px text ladder
-```
-
-**Savings**: 12 nodes → 1 node (11 nodes saved)
-
-#### Example 2: Decorative Elements
-
-**❌ Detailed Bar Chart (wastes 8 nodes)**:
-
-```yaml
-- id: bar_1
-  label: ""
-  bounds: { x: 100, y: 512, width: 18, height: 36 }
-  style: { fillColor: "#22C55E" }
-
-- id: bar_2
-  label: ""
-  bounds: { x: 122, y: 524, width: 18, height: 24 }
-  style: { fillColor: "#4ADE80" }
-# ... 6 more bars
-```
-
-**✅ Simplified Representation (1 node)**:
-
-```yaml
-- id: attention_weights
-  label: "ωₜ weight bars (t=1..L)"
-  bounds: { x: 100, y: 512, width: 320, height: 48 }
-  style:
-    fillColor: "#E8F5E9"
-    strokeColor: "#16A34A"
-```
-
-**Savings**: 8 nodes → 1 node (7 nodes saved)
-
-### When to Split
-
-Split into multiple figures when:
-
-- Node count approaches 50 and simplification is not practical
-- The diagram explains 3+ distinct mechanisms or stages
-- Readers would need to zoom in to read labels at normal page size
-- The figure serves multiple purposes (e.g., architecture + training procedure)
-
-### Split Strategies
-
-**By data path** (for multi-input or multi-branch systems):
-
-- Figure 3a: High-frequency processing path
-- Figure 3b: Low-frequency conditioning path
-- Both figures share the same fusion/output stage context in captions
-
-**By hierarchy level** (for deep architectures):
-
-- Figure 3a: System overview (4-6 major modules)
-- Figure 3b: Detailed view of the fusion module
-- Figure 3c: Attention mechanism internals
-
-**By mechanism** (for multi-stage methods):
-
-- Figure 3a: Feature extraction stage
-- Figure 3b: Conditional fusion mechanism
-- Figure 3c: Temporal attention and regression
-
-**Real-world example from IEEE papers**:
-
-- Typical neural network figures: 25-35 nodes
-- Complex architectures often split into 2-3 sub-figures
-- Main figure shows 4-6 modules; detail figures zoom into 1-2 modules
-
-## Canvas and Print Sizing
-
-A figure is scaled to the column width of the paper, so canvas pixels have no fixed print size. When a figure is placed at full column width:
-
-```
-effective pt = fontSize x print-width-pt / canvas-width-px
-```
-
-Print targets (set `meta.print` to opt in):
-
-| `meta.print.target` | Width          | Label floor |
-| ------------------- | -------------- | ----------- |
-| `cn-thesis`         | 155mm = 440pt  | 9pt (小五)  |
-| `ieee-single`       | 3.5in = 252pt  | 8pt         |
-| `ieee-double`       | 7.16in = 516pt | 8pt         |
-
-`meta.print: { target: cn-thesis }` (or custom `widthPt` / `minPt`) makes the validator check every figure. Without `meta.print`, only canvases wider than 1500px are checked, against the IEEE single-column floor.
-
-**Minimum label fontSize for the floor to hold**:
-
-| Canvas width | cn-thesis (440pt/9pt) | Single column (252pt/8pt) | Double column (516pt/8pt) |
-| ------------ | --------------------- | ------------------------- | ------------------------- |
-| 630px        | 13                    | 20                        | 10                        |
-| 800px        | 17                    | 26                        | 13                        |
-| 1000px       | 21                    | 32                        | 16                        |
-| 1200px       | 25                    | 39                        | 19                        |
-| 1600px       | 33                    | 51                        | 25                        |
-
-Practical prescriptions:
-
-- Let the font ladder work: without explicit `style.fontSize`, labels get module 22 / node 20 / edge 18 / text 16 and boxes grow to fit, so layout density — not font size — decides the canvas width.
-- Pick `meta.print` from the venue first, then keep the canvas narrow enough for the table above; split the figure before shrinking fonts.
-- Wide architecture figures are double-column or full-text-width material; do not squeeze them into a single column.
-- IEEE vector submissions accept PS/EPS/PDF only (SVG is not on the list). Export a PDF via draw.io Desktop for IEEE targets.
-
-## Final Quality Gate
-
-Do not consider the figure complete until all of these are true:
-
-- `meta.figureType` is set correctly
-- the diagram reads clearly at normal A4 page zoom
-- colors are not the only carrier of meaning
-- the selected palette matches the venue mapping and its colorblind/grayscale flags are reported
-- grayscale-unsafe print selections are replaced with `ieee-bw` or `tol-high-contrast`, or the strict validation failure remains explicit
-- labels are concise and readable
-- connector routing is clean enough that the reading order is obvious
-- the offline bundle and SVG are aligned
-- any visual self-check used the exported SVG or Desktop-exported final artifact before any browser/live screenshot
-- any requested PNG companion matches the final diagram state

package/template/.codex/skills/drawio-academic-skills/references/docs/publication-overlay.md

@@ -1,206 +0,0 @@
-# Academic Publication Overlay
-
-This file contains overlay-only policy for `drawio-academic-skills`. Shared schemas, CLI commands, design-system references, official XML/style mirrors, examples, themes, and workflow guides live in the sibling base skill at `../drawio`.
-
-## Overlay Responsibility
-
-Use this overlay when the request is publication-facing:
-
-- paper, thesis, journal, IEEE, manuscript, camera-ready, or publication-ready figure
-- A4 or Word/LaTeX export expectations
-- academic formula figure or paper diagram replication
-- research workflow, system architecture paper figure, or scholarly roadmap
-
-## Required Academic Decisions
-
-Before rendering, decide:
-
-1. Venue or audience.
-2. `meta.figureType`: `architecture`, `roadmap`, or `workflow`.
-3. Palette selection and safety policy: venue recommendation, colorblind safety, and grayscale/print safety.
-4. Caption and legend requirements.
-5. Formula/text placement fidelity.
-6. Requested exports and whether draw.io Desktop is required.
-
-## Palette and Print Policy
-
-Use the single venue mapping in `academic-figure-playbook.md § Venue Palette Mapping`; do not maintain a second recommendation table here. Theme and palette remain independent: theme owns academic typography/layout treatment, while `meta.palette` supplies category colors.
-
-When `meta.print.target` is `cn-thesis`, `ieee-single`, or `ieee-double`, a selected palette with `grayscaleSafe: false` emits `PALETTE_PRINT_GATE`. Normal validation reports a warning; strict validation escalates it to an error and recommends `ieee-bw` or `tol-high-contrast`. A non-colorblind-safe academic palette emits `PALETTE_CVD_NOTICE` as info so an intentional aesthetic choice remains possible.
-
-Completion reports name the selected palette, its colorblind/grayscale safety flags, and any print-gate downgrade.
-
-## Source Understanding
-
-Use the source mode before drafting YAML:
-
-- Document or paper: extract the research problem, gap, objective, theory or assumptions, data, method, mechanism, validation, metrics, findings, and contribution.
-- Reference image: extract visible containers, swimlanes, section labels, nodes, arrows, captions, legends, formulas, colors, line styles, and ambiguous text.
-- Text-only request: infer a compact academic figure plan and keep assumptions explicit.
-
-For paper-derived figures, classify the source first:
-
-| Source type                     | Figure pattern                                                                                |
-| ------------------------------- | --------------------------------------------------------------------------------------------- |
-| Algorithm or optimization paper | inputs -> assumptions -> model stages -> execution -> feedback -> scenarios -> metrics        |
-| Empirical study                 | question -> hypotheses/constructs -> data/sample -> variables -> method -> checks -> findings |
-| Mechanism study                 | antecedents -> mediators -> moderators/boundaries -> outcomes -> evidence                     |
-| System architecture paper       | data/sensing -> processing modules -> decision/control -> outputs -> evaluation               |
-| Experimental study              | problem -> setup -> treatment/control -> measurement -> analysis -> findings                  |
-| Review or policy paper          | problem space -> classification -> evidence groups -> synthesis -> gaps/recommendations       |
-| Deep-learning model paper       | input -> backbone/encoder -> fusion/attention -> head/decoder -> loss/output -> metrics       |
-| Algorithm mechanism figure      | local inputs -> operation window -> formula/operator -> output -> interpretation              |
-
-Map the result to the existing `meta.figureType` contract:
-
-- `architecture`: structure, layers, modules, systems, actors, or static relationships.
-- `roadmap`: study stages, milestones, phases, or progressive deliverables.
-- `workflow`: ordered execution, branching, iterative methods, experiments, or pipelines.
-
-## Scientific Figure Planning
-
-When the source is a research model, mechanism, or experiment, turn the evidence chain into a compact figure plan before drafting YAML. The figure-type pattern library (model architecture, operation/mechanism, experiment pipeline, scholarly framework redraw — each with its YAML emphasis) lives in `academic-figure-playbook.md § Scientific Figure Patterns`; use it rather than re-deriving patterns here.
-
-Prefer an architecture figure for static relationships and a workflow figure for ordered operations. Do not invent a new `meta.figureType` when the existing three values can express the paper role.
-
-## Research Evidence Chain
-
-Extract a compact evidence chain before proposing the figure:
-
-1. Research problem and gap.
-2. Objective or research question.
-3. Inputs, data sources, sample, variables, or operating conditions.
-4. Theory, assumptions, hypotheses, constructs, or constraints.
-5. Core method, model, algorithm, mechanism, or framework.
-6. Actors, system components, scenarios, or process stages.
-7. Outputs, experiments, validation methods, metrics, and results.
-8. Main contribution, implications, limitations, or future-work hook.
-9. Feedback loops, uncertainty, or boundary conditions when they affect interpretation.
-
-Do not force every item into the figure. Include the items that explain the paper's argument and distinguish the proposed approach.
-
-## Diagram Plan Gate
-
-For complex paper-derived figures, ambiguous diagrams, or academic image-improvement work, confirm a diagram plan before rendering. Use this template:
-
-```text
-Source type:
-Figure type:
-Primary research chain:
-Major sections:
-Supporting nodes:
-Key arrows and feedback:
-Formula/callout placement:
-Validation and contribution:
-Preview path:
-Terms needing confirmation:
-```
-
-Skip this gate only for simple academic diagrams where the user already gave the figure type, labels, layout, and export expectations clearly.
-
-## Content Compression
-
-Academic figures should not copy paragraphs into boxes. Compress source text into:
-
-- noun phrases for modules,
-- verb phrases for arrows,
-- short method labels for algorithm or experiment steps,
-- short result labels for validation or findings,
-- one-line notes for assumptions, constraints, or limitations.
-
-Prefer 4-8 major modules and 2-5 supporting nodes per major section. Use one dominant reading path and only 1-2 feedback loops unless the source genuinely requires more.
-
-For model-architecture and mechanism figures, compress repeated layers into stage labels such as `CSP block x3`, `Feature fusion`, or `Detect head` instead of drawing every internal layer. Use a legend or caption to explain notation that repeats across the figure.
-
-## Text and Callout Styling
-
-Captions, callouts, legends, and annotation labels follow the base rule in `../drawio/references/docs/design-system/tokens.md` § Text & Label Styling. Two points matter most for publication figures:
-
-- **Transparent, no white box.** Plain text boxes always render `fillColor=none;strokeColor=none;labelBackgroundColor=none` — the base converter enforces this and warns on white fills. A white rectangle behind text occludes the figure and reads as unfinished in a paper; if a label sits on a busy region, prefer a darker font or relocation, and use a `formula` node or shape node with a restrained tint as the deliberate exception — never a hard `#FFFFFF` block.
-- **Content-sized boxes.** Size a text/callout box just wider than its longest line, not to a container or source-image region, so captions and callouts stay independently placeable and do not overlap modules or connectors. Vertical CJK labels are one character per line with explicit newlines.
-- **Native straight connectors.** Publication figures follow the base edge rules: bound edges only (no arrow-shape stand-ins), collinear no-waypoint orthogonal edges, and bold `endSize=12` open heads (unfilled "V"; block/classic only on explicit request, UML/ER markers keep their own fill); run `--validate --strict` before export.
-
-## Optional Image Preview
-
-Use external image-generation preview by default for:
-
-- complex paper-derived figures with non-obvious layout or hierarchy,
-- reference-image redraws where the user wants academic improvement rather than literal replication,
-- proposal/thesis/manuscript figures where visual composition needs approval before YAML work.
-
-Skip external image-generation preview for simple, straightforward academic diagrams and proceed directly to YAML/SVG.
-
-Privacy rules:
-
-- Ask before sending unpublished papers, confidential reports, proprietary data, or sensitive research content to an external model.
-- Prefer sending the confirmed diagram plan, short labels, layout intent, and visual style constraints instead of raw source documents.
-- If the user declines external processing, no image tool is available, or generation fails, fall back to local YAML/SVG preview.
-
-Prompt constraints:
-
-- Request academic diagram style, not a poster or marketing graphic.
-- Use white or very light background, restrained colors, thin borders, clear hierarchy, and short labels.
-- Ask for boxes, containers, swimlanes, callouts, feedback loops, and orthogonal arrows only when supported by the plan.
-- Avoid decorative gradients, stock imagery, icons used as decoration, heavy shadows, and diagonal connector arrows.
-- Treat generated text as approximate. Correct exact labels, formulas, and captions in YAML.
-
-## Bundle Contract
-
-Default academic final delivery is:
-
-- `.drawio`
-- `.svg`
-
-Work-dir sidecars are still part of the reproducible bundle, but should live in a project-local work directory by default:
-
-- `.spec.yaml`
-- `.arch.json`
-
-PNG/PDF/JPG are optional Desktop-enhanced exports. If Desktop is unavailable, report the missing export and provide the editable `.drawio`, SVG, work-dir sidecars, and fallback command or URL.
-
-IEEE vector submissions accept PS/EPS/PDF only (SVG is not on the accepted list). When the target venue is IEEE or applies similar rules, recommend a Desktop-exported PDF alongside the standard bundle; the default `.drawio` + `.svg` contract stays unchanged.
-
-## Visual Verification
-
-Use exported artifacts for paper-readability checks before any browser path:
-
-Apply the shared preview, structured issue, YAML-first rework, and stopping contract from `../../../drawio/references/workflows/visual-review.md`. This overlay adds the publication checks below; it does not redefine the shared issue taxonomy or runtime.
-
-1. Inspect the generated SVG when the current environment can view it.
-2. If a raster or final-fidelity check is needed and draw.io Desktop is available, inspect the Desktop-exported PNG/PDF/JPG or embedded `.drawio.svg`.
-3. Do not substitute browser or Playwright screenshots when an exported artifact exists.
-4. Use live/browser screenshots only as a last-resort review aid when the user explicitly requested live review and no exported artifact can be inspected.
-
-For the first exported artifact, check:
-
-- overlap between modules, labels, captions, legends, or formula blocks;
-- clipped text or formula rendering issues;
-- connector labels sitting on top of lines;
-- arrows crossing text or node interiors;
-- missing modules, wrong grouping, or visual mismatch from the confirmed plan/source;
-- colors being the only carrier of meaning.
-
-If a visible defect is found, adjust the YAML spec and rerender once. Any further correction follows the shared loop limits. Academic review additionally requires A4 readability, caption/legend integrity, formula fidelity, and print-safe meaning before reporting the result.
-
-For a projection drift figure, keep the base runtime and report unchanged.
-Publication review must preserve the explicit `[ADDED]`, `[REMOVED]`,
-`[CHANGED]`, and `[UNCHANGED]` text, the legend, changed-key evidence, and the
-dashed removed relation in grayscale/print output. The academic overlay may
-adjust typography and placement only; it must not copy or reinterpret the
-snapshot adapter or comparator.
-
-## References
-
-Load these overlay-local academic references for detailed rules:
-
-- `academic-figure-playbook.md` (figure-type pattern library and node budget)
-- `academic-export-checklist.md`
-
-Load the sibling base references for shared execution detail:
-
-- `../drawio/references/docs/math-typesetting.md`
-- `../drawio/references/docs/design-system/specification.md`
-- `../drawio/references/docs/design-system/tokens.md`
-- `../drawio/references/workflows/create.md`
-- `../drawio/references/workflows/edit.md`
-- `../drawio/references/workflows/replicate.md`

package/template/.codex/skills/drawio-academic-skills/references/examples/ablation-study-pipeline.yaml

@@ -1,39 +0,0 @@
-meta:
-  profile: academic-paper
-  figureType: workflow
-  theme: academic-color
-  layout: vertical
-  title: "Ablation Study Pipeline"
-  description: "Compare baseline, variant, and evaluation stages."
-  legend: "Each branch is an ablation configuration. Shared evaluation is shown with dashed input aggregation."
-
-nodes:
-  - id: baseline
-    label: Baseline
-    type: service
-  - id: variantA
-    label: Variant A
-    type: service
-  - id: variantB
-    label: Variant B
-    type: service
-  - id: eval
-    label: Evaluation
-    type: process
-  - id: report
-    label: Report
-    type: document
-
-edges:
-  - from: baseline
-    to: eval
-    type: data
-  - from: variantA
-    to: eval
-    type: data
-  - from: variantB
-    to: eval
-    type: data
-  - from: eval
-    to: report
-    type: primary

package/template/.codex/skills/drawio-academic-skills/references/examples/ieee-network-paper.yaml

@@ -1,44 +0,0 @@
-meta:
-  profile: academic-paper
-  figureType: architecture
-  theme: academic
-  layout: vertical
-  title: "Fig. 1. Campus Network Topology"
-  description: "Core, distribution, and access layers for an IEEE-style paper figure."
-  legend: "Solid lines are physical links. Dashed lines are management or control links."
-
-nodes:
-  - id: core
-    label: Core Router
-    type: service
-  - id: distA
-    label: Distribution A
-    type: service
-  - id: distB
-    label: Distribution B
-    type: service
-  - id: access
-    label: Access Switch
-    type: service
-  - id: users
-    label: User Segment
-    type: user
-
-edges:
-  - from: core
-    to: distA
-    type: primary
-  - from: core
-    to: distB
-    type: primary
-  - from: distA
-    to: access
-    type: primary
-  - from: distB
-    to: access
-    type: data
-    label: Control
-    style: { fontSize: 10 }
-  - from: access
-    to: users
-    type: primary