kotonoha 0.1.2 → 0.1.4

package/skills/presentation-planner/assets/design-templates/data-report.yaml

@@ -0,0 +1,97 @@
+id: data-report
+base_template: null
+intent:
+  - KPI review
+  - research findings
+  - operational report
+  - analytical recommendation
+canvas:
+  aspect_ratio: "16:9"
+  width_in: 13.333
+  height_in: 7.5
+  safe_area_percent: 6
+  grid_columns: 12
+  max_content_blocks: 4
+colors:
+  background: "#FFFFFF"
+  surface: "#F3F3F3"
+  text_primary: "#1B1B1B"
+  text_secondary: "#505050"
+  accent: "#005A9E"
+  accent_soft: "#E5F1FB"
+  border_neutral: "#8A8886"
+  positive: "#107C10"
+  warning: "#8A5A00"
+  critical: "#A4262C"
+  brand_red: "#F25022"
+  brand_green: "#7FBA00"
+  brand_blue: "#00A4EF"
+  brand_yellow: "#FFB900"
+  chart_sequence:
+    - "#005A9E"
+    - "#F25022"
+    - "#767676"
+typography:
+  heading_font: "Aptos Display"
+  body_font: "Aptos"
+  numeric_font: "Aptos"
+  title_size_pt: 28
+  section_title_size_pt: 24
+  body_size_pt: 17
+  metric_size_pt: 34
+  caption_size_pt: 10
+  title_weight: 700
+  body_line_spacing: 1.12
+spacing:
+  outer_margin_percent: 6
+  content_gap_percent: 2
+  card_padding_percent: 2
+components:
+  cards:
+    corner_radius: medium
+    border: none
+    shadow: none
+  callouts:
+    use_accent_bar: false
+    maximum_per_slide: 1
+  tables:
+    header_fill: accent_soft
+    header_text: text_primary
+    zebra_rows: true
+    maximum_rows: 8
+  charts:
+    style: analytical
+    gridlines: minimal
+    direct_labels_required: true
+    series_outline: background
+    source_note_required: true
+    zero_baseline_required_for_bars: true
+  diagrams:
+    connector_style: simple
+    maximum_nodes: 6
+slide_patterns:
+  - title
+  - key-findings
+  - metric-scorecard
+  - trend
+  - comparison
+  - distribution
+  - drivers
+  - implication
+  - recommendation
+  - appendix-method
+accessibility:
+  minimum_body_size_pt: 15
+  minimum_contrast_ratio: 4.5
+  never_use_color_alone: true
+  alt_text_required: true
+constraints:
+  - one primary message per slide
+  - assertion title required
+  - chart axes and units must be visible
+  - uncertainty and sample size must be disclosed
+  - three-dimensional charts are prohibited
+  - Microsoft logo colors are not used for small text on white
+  - brand_yellow uses a direct label and pattern or marker encoding
+  - charts with more than three series add pattern or shape encoding
+deviations: []

package/skills/presentation-planner/assets/design-templates/executive-proposal.yaml

@@ -0,0 +1,92 @@
+id: executive-proposal
+base_template: null
+intent:
+  - executive decision
+  - investment approval
+  - transformation roadmap
+  - technical proposal
+canvas:
+  aspect_ratio: "16:9"
+  width_in: 13.333
+  height_in: 7.5
+  safe_area_percent: 6
+  grid_columns: 12
+  max_content_blocks: 4
+colors:
+  background: "#FFFFFF"
+  surface: "#F3F3F3"
+  text_primary: "#1B1B1B"
+  text_secondary: "#505050"
+  accent: "#005A9E"
+  accent_soft: "#E5F1FB"
+  border_neutral: "#8A8886"
+  positive: "#107C10"
+  warning: "#8A5A00"
+  critical: "#A4262C"
+  brand_red: "#F25022"
+  brand_green: "#7FBA00"
+  brand_blue: "#00A4EF"
+  brand_yellow: "#FFB900"
+  chart_sequence:
+    - "#005A9E"
+    - "#F25022"
+    - "#767676"
+typography:
+  heading_font: "Aptos Display"
+  body_font: "Aptos"
+  title_size_pt: 30
+  section_title_size_pt: 26
+  body_size_pt: 18
+  caption_size_pt: 11
+  title_weight: 700
+  body_line_spacing: 1.15
+spacing:
+  outer_margin_percent: 6
+  content_gap_percent: 2
+  card_padding_percent: 2
+components:
+  cards:
+    corner_radius: medium
+    border: none
+    shadow: subtle
+  callouts:
+    use_accent_bar: true
+    maximum_per_slide: 1
+  tables:
+    header_fill: accent_soft
+    header_text: text_primary
+    zebra_rows: true
+    maximum_rows: 7
+  charts:
+    style: direct-label
+    gridlines: minimal
+    direct_labels_required: true
+    series_outline: background
+    source_note_required: true
+  diagrams:
+    connector_style: orthogonal
+    maximum_nodes: 7
+slide_patterns:
+  - title
+  - executive-summary
+  - problem-evidence
+  - option-comparison
+  - recommendation
+  - roadmap
+  - investment-and-value
+  - risk-and-mitigation
+  - decision-request
+accessibility:
+  minimum_body_size_pt: 16
+  minimum_contrast_ratio: 4.5
+  never_use_color_alone: true
+  alt_text_required: true
+constraints:
+  - one primary message per slide
+  - assertion title required
+  - no more than one chart per slide
+  - no decorative stock imagery without narrative value
+  - Microsoft logo colors are not used for small text on white
+  - brand_yellow uses a direct label and pattern or marker encoding
+  - charts with more than three series add pattern or shape encoding
+deviations: []

package/skills/presentation-planner/assets/design-templates/technical-briefing.yaml

@@ -0,0 +1,96 @@
+id: technical-briefing
+base_template: null
+intent:
+  - architecture explanation
+  - engineering review
+  - technical proposal
+  - implementation briefing
+canvas:
+  aspect_ratio: "16:9"
+  width_in: 13.333
+  height_in: 7.5
+  safe_area_percent: 5
+  grid_columns: 12
+  max_content_blocks: 5
+colors:
+  background: "#FFFFFF"
+  surface: "#F3F3F3"
+  text_primary: "#1B1B1B"
+  text_secondary: "#505050"
+  accent: "#005A9E"
+  accent_soft: "#E5F1FB"
+  border_neutral: "#8A8886"
+  positive: "#107C10"
+  warning: "#8A5A00"
+  critical: "#A4262C"
+  brand_red: "#F25022"
+  brand_green: "#7FBA00"
+  brand_blue: "#00A4EF"
+  brand_yellow: "#FFB900"
+  chart_sequence:
+    - "#005A9E"
+    - "#F25022"
+    - "#767676"
+typography:
+  heading_font: "Aptos Display"
+  body_font: "Aptos"
+  code_font: "Cascadia Mono"
+  title_size_pt: 28
+  section_title_size_pt: 24
+  body_size_pt: 17
+  code_size_pt: 13
+  caption_size_pt: 10
+  title_weight: 700
+  body_line_spacing: 1.12
+spacing:
+  outer_margin_percent: 5
+  content_gap_percent: 1.5
+  card_padding_percent: 1.5
+components:
+  cards:
+    corner_radius: small
+    border: border_neutral
+    shadow: none
+  callouts:
+    use_accent_bar: true
+    maximum_per_slide: 2
+  tables:
+    header_fill: accent_soft
+    header_text: text_primary
+    zebra_rows: false
+    maximum_rows: 8
+  charts:
+    style: technical
+    gridlines: subtle
+    direct_labels_required: true
+    series_outline: background
+    source_note_required: true
+  diagrams:
+    connector_style: orthogonal
+    maximum_nodes: 9
+    boundary_labels_required: true
+slide_patterns:
+  - title
+  - system-context
+  - architecture
+  - sequence-or-flow
+  - component-responsibilities
+  - interface-and-data
+  - security-boundaries
+  - implementation-plan
+  - tradeoffs
+  - decision-request
+accessibility:
+  minimum_body_size_pt: 15
+  minimum_contrast_ratio: 4.5
+  never_use_color_alone: true
+  alt_text_required: true
+constraints:
+  - one primary message per slide
+  - assertion title required
+  - code samples limited to twelve visible lines
+  - diagrams must identify trust or ownership boundaries
+  - Microsoft logo colors are not used for small text on white
+  - brand_yellow uses a direct label and pattern or marker encoding
+  - charts with more than three series add pattern or shape encoding
+deviations: []

package/skills/presentation-planner/assets/scenario-templates/data-report.md

@@ -0,0 +1,47 @@
+# Data report presentation scenario
+
+Use this scenario for KPI reviews, research findings, operational analysis,
+experiments, surveys, or evidence-led recommendations.
+
+- Working title: <presentation title>
+- Audience: <decision-makers or analysts>
+- Question to answer: <one analytical question>
+- Decision or action enabled: <outcome>
+- Analysis period: <date range>
+- Data sources: <systems, files, studies>
+- Target slide count: <count or range>
+
+## Scenario arc
+
+| Stage | Audience question | Assertion to establish | Required evidence | Transition to next stage | Suggested slides |
+|---|---|---|---|---|---:|
+| Question | What decision-relevant question does the analysis answer? | <the question and success measure are unambiguous> | <business context, metric definition> | Explain whether the data can answer it credibly | 1 |
+| Method | How reliable and comparable is the analysis? | <scope, source, sample, and method support the conclusion> | <definitions, coverage, exclusions> | Present the most decision-relevant findings first | 1 |
+| Finding | What changed or differs materially? | <one quantified finding per slide> | <chart, table, confidence, baseline> | Move from observation to explanation | 2–4 |
+| Interpretation | Why did it happen and what uncertainty remains? | <drivers and limitations explain the finding without overstating causality> | <segmentation, comparison, caveats> | Translate the finding into impact | 1–2 |
+| Impact | Why does the result matter? | <finding changes cost, risk, experience, or opportunity> | <scenario, forecast, affected population> | Compare available responses | 1–2 |
+| Recommendation | What action follows from the evidence? | <recommended action is proportional to evidence and uncertainty> | <options, expected effect, cost> | Define measurement and ownership | 1–2 |
+| Next measure | How will we know the action worked? | <owner, metric, target, and review date close the loop> | <measurement plan> | End with the required decision or action | 1 |
+
+## Claim and evidence register
+
+| Claim | Metric definition | Source | Analysis period | Confidence | Caveat |
+|---|---|---|---|---|---|
+| <claim> | <numerator, denominator, unit> | <source> | <period> | High / Medium / Low | <limitation> |
+
+## Analytical integrity checks
+
+- Baseline and comparison periods: <definitions>
+- Population, sample, and exclusions: <definitions>
+- Missing data and outliers: <treatment>
+- Correlation versus causation: <allowed conclusion>
+- Statistical or practical significance: <threshold>
+- Reproducibility: <query, notebook, report, owner>
+
+## Scenario acceptance checks
+
+- The analytical question and metric definitions precede the findings.
+- Each finding slide states one quantified conclusion, unit, period, and source.
+- Limitations and uncertainty appear before recommendations.
+- Recommendations are proportional to the strength of the evidence.
+- The final stage assigns an action, metric, owner, and review date.

package/skills/presentation-planner/assets/scenario-templates/executive-decision.md

@@ -0,0 +1,43 @@
+# Executive decision presentation scenario
+
+Use this scenario when executives or accountable sponsors must approve an
+investment, architecture, roadmap, policy, or delivery decision.
+
+- Working title: <presentation title>
+- Audience: <decision-makers and prior knowledge>
+- Decision required: <one explicit approval or choice>
+- Decision deadline: <date or meeting>
+- Current audience position: <what they believe or question now>
+- Intended final position: <what they should believe and do>
+- Target slide count: <count or range>
+
+## Scenario arc
+
+| Stage | Audience question | Assertion to establish | Required evidence | Transition to next stage | Suggested slides |
+|---|---|---|---|---|---:|
+| Context | Why does this require attention now? | <change, deadline, or opportunity makes action timely> | <external change, KPI, commitment> | If action is timely, show the consequence of inaction | 1–2 |
+| Tension | What happens if we continue as-is? | <current state creates measurable cost, risk, or delay> | <baseline, incident, trend, user impact> | Once the gap is credible, define the decision criteria | 1–2 |
+| Criteria | How should the options be judged? | <shared cost, value, risk, and feasibility criteria> | <constraints, targets, policy> | Compare options using the agreed criteria | 1 |
+| Options | What choices are realistically available? | <credible alternatives include the status quo> | <comparable analysis> | Identify the option that best satisfies the criteria | 1–2 |
+| Recommendation | What should we choose and why? | <recommended option delivers the best justified outcome> | <benefits, trade-offs, TCO, evidence> | Show that execution risk is controlled | 1–2 |
+| Plan | Can this be delivered safely? | <owners, milestones, controls, and rollback make delivery feasible> | <roadmap, staffing, risk controls> | Convert confidence into a precise decision | 1–2 |
+| Decision | What exactly must be approved today? | <specific approval, funding, owner, and next checkpoint> | <decision wording and consequences> | End with the requested action | 1 |
+
+## Evidence gaps and assumptions
+
+| Claim needed by the scenario | Source | Status | Assumption or follow-up |
+|---|---|---|---|
+| <claim> | <file, URL, owner> | Verified / Assumption / Missing | <action> |
+
+## Objections to resolve
+
+| Likely objection | Where it is answered | Evidence or concession |
+|---|---|---|
+| <cost, risk, timing, alternative> | <scenario stage> | <response> |
+
+## Scenario acceptance checks
+
+- Reading only the assertions forms a complete decision argument.
+- The status quo and at least one alternative use the same evaluation axes.
+- Benefits, cost, risks, and delivery controls are evidence-based.
+- The final stage asks for one explicit decision with an owner and deadline.

package/skills/presentation-planner/assets/scenario-templates/technical-briefing.md

@@ -0,0 +1,45 @@
+# Technical briefing presentation scenario
+
+Use this scenario to explain an architecture, engineering change, technical
+proposal, system behavior, or implementation approach to a technical audience.
+
+- Working title: <presentation title>
+- Audience: <engineers, architects, operators, reviewers>
+- Prior-knowledge floor: <what can be assumed>
+- Understanding or decision required: <outcome>
+- Technical depth: Overview / Working knowledge / Review-ready
+- Target slide count: <count or range>
+
+## Scenario arc
+
+| Stage | Audience question | Assertion to establish | Required evidence | Transition to next stage | Suggested slides |
+|---|---|---|---|---|---:|
+| Context | What system and constraint are we discussing? | <boundary, users, and constraints define the problem> | <context diagram, requirements> | Show where the current design fails or must change | 1–2 |
+| Problem | What technical problem must be solved? | <specific quality or delivery gap requires a design response> | <failure mode, measurement, limitation> | State the design drivers used to judge solutions | 1–2 |
+| Drivers | What properties matter most? | <requirements and quality attributes determine the design> | <NFRs, constraints, priorities> | Introduce the architecture that satisfies them | 1 |
+| Architecture | How is the solution structured? | <components and boundaries assign clear responsibilities> | <context, container, deployment diagrams> | Walk through the critical behavior | 2–3 |
+| Flow | What happens in the important scenarios? | <data and control flow meet functional and failure requirements> | <sequence, state, data flow> | Examine trade-offs and failure behavior | 1–3 |
+| Trade-offs | Why this design instead of alternatives? | <accepted costs are justified by the design drivers> | <alternatives, benchmarks, risks> | Show that the design can be operated and evolved | 1–2 |
+| Operations | How will it be secured, observed, scaled, and recovered? | <operational controls make the design production-ready> | <SLO, threat controls, runbook, capacity> | Close with implementation or review actions | 1–2 |
+| Next step | What must the audience do next? | <review decision, implementation step, or open issue is explicit> | <owners, dates, unresolved decisions> | End with the required action | 1 |
+
+## Technical evidence map
+
+| Assertion | Requirement or decision ID | Source artifact | Confidence | Missing validation |
+|---|---|---|---|---|
+| <assertion> | <FR/NFR/ADR/Issue> | <file or URL> | High / Medium / Low | <test or review> |
+
+## Complexity controls
+
+- Terms requiring definition: <terms>
+- Details delegated to appendix: <schemas, exhaustive tables, code>
+- Diagrams required: <context, sequence, data, deployment>
+- Known limitations: <unsupported or deferred behavior>
+
+## Scenario acceptance checks
+
+- The system boundary and design drivers appear before component detail.
+- Architecture diagrams and processing flows carry the primary explanation.
+- Alternatives and accepted trade-offs are explicit.
+- Security, operation, failure, and recovery behavior are not deferred silently.
+- The final stage identifies a review decision or implementation action.

package/skills/presentation-planner/references/customizing-design-templates.md

@@ -0,0 +1,160 @@
+# Customizing presentation design templates
+
+Use this guide to adapt a packaged design for one presentation or to add a
+new reusable design to kotonoha. Design templates are YAML specifications;
+they are not `.pptx` theme files and do not replace the host's PPTX creation
+skill.
+
+## Choose between a deck override and a packaged template
+
+Use a **deck override** when one presentation needs different colors, type,
+spacing, or component behavior. Copy a packaged design into:
+
+```text
+.presentation/<deck-slug>/design-spec.yaml
+```
+
+Use a **new packaged template** only when the design will be reused across
+multiple presentations or teams. Add it under:
+
+```text
+skills/presentation-planner/assets/design-templates/<template-id>.yaml
+```
+
+Do not edit a packaged template merely to customize one deck; that changes
+future presentations and makes upgrades harder to compare.
+
+## Copy and identify an adapted design
+
+1. Copy the closest packaged YAML file to the deck directory.
+2. Set `base_template` to the packaged template's original `id`.
+3. Change `id` to a deck-specific value such as
+   `<deck-slug>:<base-template>`.
+4. Keep every documented top-level key from
+   `design-spec-schema.md`.
+5. Record intentional changes under `deviations`.
+
+Example:
+
+```yaml
+id: migration-proposal:executive-proposal
+base_template: executive-proposal
+deviations:
+  - "Use the customer-approved heading font."
+  - "Increase the table row limit from 7 to 9 for the appendix."
+```
+
+## Change colors by semantic role
+
+Change the meaning-bearing token rather than replacing colors wherever they
+appear.
+
+```yaml
+colors:
+  background: "#FFFFFF"
+  surface: "#F3F3F3"
+  text_primary: "#1B1B1B"
+  text_secondary: "#505050"
+  accent: "#005A9E"
+  accent_soft: "#E5F1FB"
+  border_neutral: "#8A8886"
+  positive: "#107C10"
+  warning: "#8A5A00"
+  critical: "#A4262C"
+```
+
+The packaged designs expose Microsoft's corporate logo colors as brand
+tokens:
+
+```yaml
+brand_red: "#F25022"
+brand_green: "#7FBA00"
+brand_blue: "#00A4EF"
+brand_yellow: "#FFB900"
+```
+
+Keep the following rules when changing the palette:
+
+- Keep `background` white unless the presentation requirement explicitly
+  overrides the packaged visual direction.
+- Maintain at least the declared `minimum_contrast_ratio` for text.
+- Do not use the four logo colors for small text on white without checking
+  the actual contrast.
+- Give `brand_yellow` and other low-contrast chart series a direct label plus
+  pattern or marker encoding.
+- Never use color as the only way to communicate status or series identity.
+- Keep categorical charts to the packaged three-series sequence where
+  possible; use pattern, marker, or shape encoding for additional series.
+
+## Change typography and spacing
+
+Update font families only when the target environment has them or the PPTX
+skill can embed or substitute them predictably.
+
+```yaml
+typography:
+  heading_font: "Aptos Display"
+  body_font: "Aptos"
+  title_size_pt: 30
+  body_size_pt: 18
+
+spacing:
+  outer_margin_percent: 6
+  content_gap_percent: 2
+  card_padding_percent: 2
+```
+
+- Keep body text at or above `accessibility.minimum_body_size_pt`.
+- Use percentages for margins and gaps instead of absolute object
+  coordinates.
+- Record required font substitutions in `deviations`.
+
+## Change components and slide patterns
+
+Use only values documented in `design-spec-schema.md`.
+
+```yaml
+components:
+  tables:
+    header_fill: accent_soft
+    header_text: text_primary
+    maximum_rows: 7
+  charts:
+    style: direct-label
+    gridlines: minimal
+    direct_labels_required: true
+    series_outline: background
+```
+
+`slide_patterns` declares supported presentation intents, not PowerPoint
+layout names or coordinates. Add a pattern only when the handoff can describe
+its information structure and the PPTX skill can render it without
+template-specific code in `presentation-planner`.
+
+## Validate an adapted design before handoff
+
+Check all of the following:
+
+- The YAML parses successfully.
+- All top-level keys from `design-spec-schema.md` remain present.
+- Every token reference resolves to a key under `colors`.
+- Text and table-header foreground/background pairs meet the contrast floor.
+- Chart series remain distinguishable without color alone.
+- `id`, `base_template`, and `deviations` describe the adaptation accurately.
+- The PPTX handoff points to the adapted file, not the packaged base file.
+
+If the renderer cannot implement a token or component value, update the
+design spec with an explicit fallback. Do not add PPTX generation code to
+this skill.
+
+## Add a reusable packaged template
+
+When adding a new base template:
+
+1. Add `<template-id>.yaml` under `assets/design-templates/`.
+2. Add the template to the selection table in `SKILL.md`.
+3. Document its intended and unsuitable use cases.
+4. Add the filename to the packed-artifact test in `test/install.test.js`.
+5. Update `CHANGELOG.md`.
+6. Run the repository tests, Markdown lint, YAML schema checks, and contrast
+   checks before committing.

package/skills/presentation-planner/references/design-spec-schema.md

@@ -0,0 +1,72 @@
+# Design specification schema
+
+Each packaged YAML design uses the following stable top-level keys.
+
+| Key | Purpose |
+|---|---|
+| `id` | Unique specification identifier; change it for an adapted deck |
+| `base_template` | Packaged template ID from which the spec was adapted |
+| `intent` | Presentations this design supports |
+| `canvas` | Aspect ratio, dimensions, safe area, and grid |
+| `colors` | Semantic color tokens and chart sequence |
+| `typography` | Font families, sizes, weights, and line spacing |
+| `spacing` | Margins, gaps, and density limits |
+| `components` | Cards, callouts, tables, charts, and diagrams |
+| `slide_patterns` | Supported layout intents, not binary PPTX layouts |
+| `accessibility` | Contrast, minimum type, alt text, and color-use rules |
+| `constraints` | Rules the PPTX skill must not violate |
+| `deviations` | Deliberate differences from the packaged base template |
+
+## Portable component vocabulary
+
+Use only these renderer-independent values unless a deviation explains the
+fallback:
+
+| Field | Allowed values |
+|---|---|
+| `corner_radius` | `none`, `small`, `medium`, `large` |
+| `shadow` | `none`, `subtle`, `medium` |
+| `charts.style` | `direct-label`, `technical`, `analytical` |
+| `charts.gridlines` | `none`, `subtle`, `minimal` |
+| `charts.series_outline` | `none` or an exact key under `colors` |
+| `charts.direct_labels_required` | `true` or `false` |
+| `connector_style` | `simple`, `orthogonal`, `curved` |
+| `cards.border` | `none` or an exact key under `colors` |
+| `tables.header_fill` | `none` or an exact key under `colors` |
+| `tables.header_text` | an exact key under `colors` |
+
+Values that reference a color token must exactly match a key under `colors`,
+for example `accent_soft`, not a display label such as `accent-soft`.
+Do not assume that `accent` text is readable on `accent_soft`; validate the
+actual foreground/background pair against `minimum_contrast_ratio`.
+
+The packaged designs expose Microsoft's four corporate logo colors as
+`brand_red`, `brand_green`, `brand_blue`, and `brand_yellow`. Treat them as
+brand or decorative tokens, not as an automatic categorical chart palette.
+Do not use them for small text on white unless the actual pair passes the
+contrast threshold; `brand_yellow` requires a direct label plus pattern or
+marker encoding on a white canvas.
+
+The packaged categorical `chart_sequence` is intentionally capped at three
+well-separated series: dark Microsoft blue, Microsoft red, and neutral gray.
+When a chart needs more than three series, add pattern, marker, or shape
+encoding instead of appending the remaining logo colors.
+
+`charts.series_outline: background` separates adjacent stacked, pie, or area
+segments; it does not make a light fill visible against the canvas. Use
+direct labels and pattern or marker encoding for light series.
+
+Nested typography and component keys may be omitted when irrelevant. A
+renderer must use its documented defaults for missing optional keys rather
+than treating every packaged template as an identical nested schema.
+
+## Adaptation rules
+
+- Keep the documented top-level keys stable. Optional nested keys may vary by
+  presentation intent.
+- Use brand colors only after assigning semantic roles such as `accent`,
+  `positive`, `warning`, and `critical`.
+- Do not specify absolute object coordinates. Layout engines differ; use
+  proportions, alignment, safe areas, and maximum element counts.
+- Prefer one dominant visual hierarchy per slide.
+- Record all changes from the packaged template under `deviations`.