@taylorwong/ichartjs 2.0.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (80) hide show
  1. package/CHANGELOG.md +69 -0
  2. package/LICENSE +201 -0
  3. package/README.md +194 -0
  4. package/agent-recipes/diagrams/agent-orchestration.json +18 -0
  5. package/agent-recipes/diagrams/approval-process.json +16 -0
  6. package/agent-recipes/diagrams/responsibility-mapping.json +13 -0
  7. package/agent-recipes/diagrams/workflow.json +19 -0
  8. package/agent-recipes/foundational-analysis.json +18 -0
  9. package/agent-recipes/project-management.json +47 -0
  10. package/agent-recipes/trend-line.json +21 -0
  11. package/docs/agent/README.md +62 -0
  12. package/docs/agent/charting-scenario.md +82 -0
  13. package/docs/agent/coding-agent-integration.md +88 -0
  14. package/docs/agent/development/2.0-release-readiness.md +65 -0
  15. package/docs/agent/development/iteration-2.md +9 -0
  16. package/docs/agent/development/iteration-3.md +142 -0
  17. package/docs/agent/development/iteration-4.md +261 -0
  18. package/docs/agent/development/iteration-5.md +43 -0
  19. package/docs/agent/development/iteration-6.md +130 -0
  20. package/docs/agent/development/iteration-7.md +117 -0
  21. package/docs/agent/development/iteration-8-acceptance.md +68 -0
  22. package/docs/agent/development/iteration-8.md +116 -0
  23. package/docs/agent/development/iteration-9.md +44 -0
  24. package/docs/agent/development/playground-plan.md +143 -0
  25. package/docs/agent/development/prompt-contract.md +22 -0
  26. package/docs/agent/development/rc-1-acceptance.md +43 -0
  27. package/docs/agent/development/roadmap.md +259 -0
  28. package/docs/agent/development-guide.md +60 -0
  29. package/docs/agent/diagram-scenario.md +82 -0
  30. package/docs/agent/editing-contract.md +71 -0
  31. package/docs/agent/frontend-integration.md +66 -0
  32. package/docs/agent/project-scenario.md +89 -0
  33. package/docs/agent/quickstart.md +205 -0
  34. package/docs/agent/runtime-contract.md +132 -0
  35. package/docs/agent/theme-guide.md +59 -0
  36. package/docs/agent/zh-CN/README.md +26 -0
  37. package/docs/agent/zh-CN/charting-scenario.md +62 -0
  38. package/docs/agent/zh-CN/coding-agent-integration.md +36 -0
  39. package/docs/agent/zh-CN/development-guide.md +31 -0
  40. package/docs/agent/zh-CN/diagram-scenario.md +37 -0
  41. package/docs/agent/zh-CN/editing-contract.md +27 -0
  42. package/docs/agent/zh-CN/frontend-integration.md +31 -0
  43. package/docs/agent/zh-CN/project-scenario.md +40 -0
  44. package/docs/agent/zh-CN/quickstart.md +84 -0
  45. package/docs/agent/zh-CN/runtime-contract.md +85 -0
  46. package/docs/agent/zh-CN/theme-guide.md +50 -0
  47. package/docs/manifests/capabilities.json +79 -0
  48. package/docs/manifests/commands.json +30 -0
  49. package/docs/manifests/schemas.json +13 -0
  50. package/examples/agent-workflow.mjs +94 -0
  51. package/package.json +55 -0
  52. package/skills/ichartjs/SKILL.md +72 -0
  53. package/skills/ichartjs/agents/openai.yaml +4 -0
  54. package/skills/ichartjs/references/agent-contract.md +39 -0
  55. package/skills/ichartjs/references/chart-selection.md +22 -0
  56. package/src/capabilities.mjs +190 -0
  57. package/src/charts.mjs +234 -0
  58. package/src/command.mjs +93 -0
  59. package/src/data.mjs +75 -0
  60. package/src/diagram-interaction.mjs +195 -0
  61. package/src/diagram.mjs +135 -0
  62. package/src/edit-controller.mjs +192 -0
  63. package/src/edit.mjs +369 -0
  64. package/src/format.mjs +19 -0
  65. package/src/history.mjs +14 -0
  66. package/src/index.mjs +562 -0
  67. package/src/plugin.mjs +18 -0
  68. package/src/project-analytics.mjs +357 -0
  69. package/src/project-linking.mjs +72 -0
  70. package/src/project.mjs +370 -0
  71. package/src/recipes.mjs +18 -0
  72. package/src/renderer.mjs +77 -0
  73. package/src/scale.mjs +9 -0
  74. package/src/scene.mjs +18 -0
  75. package/src/schema.mjs +142 -0
  76. package/src/spec.mjs +127 -0
  77. package/src/theme.mjs +232 -0
  78. package/src/transforms.mjs +34 -0
  79. package/src/validation.mjs +106 -0
  80. package/types/index.d.ts +134 -0
@@ -0,0 +1,60 @@
1
+ # Development Guide
2
+
3
+ Unified workflow for Coding Agents developing iChart.js 2.0.
4
+
5
+ ## Select a Scenario
6
+
7
+ | Requirement | Guide | Main source |
8
+ | --- | --- | --- |
9
+ | Generic metrics and data charts | `charting-scenario.md` | `src/charts.mjs` |
10
+ | Schedules, milestones, and progress | `project-scenario.md` | `src/project.mjs` |
11
+ | Processes, swimlanes, and Diagram editing | `diagram-scenario.md` | `src/diagram.mjs`, `src/diagram-interaction.mjs` |
12
+
13
+ ## Standard Change Flow
14
+
15
+ 1. Read `README.md`, this guide, and the relevant scenario guide.
16
+ 2. Read the current `development/iteration-X.md` to confirm scope and boundaries.
17
+ 3. Check module comments under `src/` and identify the smallest change surface.
18
+ 4. Add or adjust tests before implementing; avoid unrelated fixes.
19
+ 5. Synchronize the Manifest, scenario guide, Recipe, and Gallery.
20
+ 6. Run `npm test`, `npm run check`, and `git diff --check`.
21
+ 7. Provide the HTTP Demo URL and acceptance steps as soon as a viewable result exists.
22
+
23
+ Run `npm run agent:check` after changes. It checks the declared chart and command lists, schema model coverage, document presence, Chinese text in English core documents, and Gallery type coverage, then runs syntax checks and tests. It does not verify prose equivalence or browser behavior.
24
+
25
+ ## Change Map
26
+
27
+ ### Add a Generic Chart
28
+
29
+ - Update `src/spec.mjs` and `src/charts.mjs`.
30
+ - Add data and Scene tests.
31
+ - Update `charting-scenario.md`, `capabilities.json`, and the Gallery.
32
+
33
+ ### Add a Project Feature
34
+
35
+ - Update `src/project.mjs` and, when needed, `src/schema.mjs`.
36
+ - Add tests for analytics, tooltips, and boundary conditions.
37
+ - Update `project-scenario.md`, `schemas.json`, and the Gallery.
38
+
39
+ ### Add a Diagram Feature
40
+
41
+ - Update `src/diagram.mjs` or `src/diagram-interaction.mjs`.
42
+ - Update command validation and edit history tests.
43
+ - Update `diagram-scenario.md`, `commands.json`, and the Diagram Demo.
44
+
45
+ ## Documentation Rules
46
+
47
+ - Every active `src/*.mjs` module must have a short file-level comment.
48
+ - Add focused JSDoc for public APIs and complex algorithms; avoid line-by-line noise comments.
49
+ - Documentation describes behavior and contracts; code executes and validates them.
50
+ - Core documents directly under `docs/agent/` use English. Chinese companions belong in `docs/agent/zh-CN/`. Update both when technical contracts change.
51
+ - Development records live in `docs/agent/development/` and are not part of the default Agent context. Their existing language may be retained.
52
+
53
+ ## Completion Checklist
54
+
55
+ - Code implementation is complete.
56
+ - Unit tests are complete.
57
+ - The Manifest is synchronized.
58
+ - The scenario guide is synchronized.
59
+ - The Gallery or a focused Demo is reviewable.
60
+ - `npm run rc:check` passes.
@@ -0,0 +1,82 @@
1
+ # Scenario: Interactive Diagrams
2
+
3
+ Agent usage and development guide for process modeling, responsibility mapping, and editable diagrams.
4
+
5
+ ## Supported Types
6
+
7
+ - `flow`: a process graph made of nodes and edges.
8
+ - `swimlane`: a process graph organized by responsibility lanes.
9
+
10
+ ## Data Model
11
+
12
+ ```js
13
+ {
14
+ type: 'flow',
15
+ nodes: [{
16
+ id: 'review',
17
+ label: 'Review',
18
+ position: { x: 240, y: 100 },
19
+ size: { width: 140, height: 44 },
20
+ ports: [{ id: 'in', side: 'left', offset: 0.5 }],
21
+ groupId: 'delivery'
22
+ }],
23
+ edges: [{ from: 'start', to: 'review', toPort: 'in' }],
24
+ groups: [{ id: 'delivery', label: 'Delivery' }]
25
+ }
26
+ ```
27
+
28
+ ## Current Capabilities
29
+
30
+ Supported:
31
+
32
+ - Nodes, edges, lanes, groups, and ports.
33
+ - `manual`, `layered`, `tree`, and `radial` layouts.
34
+ - `straight`, `orthogonal`, and `curved` routing declarations, with lightweight obstacle-aware orthogonal routing.
35
+ - Node dragging, multi-selection, alignment, and grid snapping.
36
+ - Keyboard movement, copy/paste, duplicate, group collapse/expand, undo/redo, and a shared Canvas/SVG Scene.
37
+ - Port-aware drag-to-connect interaction and typed edge creation.
38
+ - Group collapse/expand with collapsed group summary rendering.
39
+
40
+ Current limitations:
41
+
42
+ - Groups are flat; nested groups are not supported.
43
+ - Group bounds are derived from member geometry and configurable `group.padding`; `resizeGroup` scales member positions and sizes rather than persisting a second group rectangle.
44
+ - `deleteGroup` defaults to `ungroup`; use `delete-members` only after explicit host confirmation.
45
+ - Canvas keeps basic accessibility text, while SVG exposes richer diagram semantics.
46
+ - Cross-browser matrix and physical-device validation remain acceptance work, not runtime guarantees.
47
+
48
+ ## Agent Workflow
49
+
50
+ 1. Assign stable IDs to nodes and edges.
51
+ 2. Use `validateDiagram(spec)` to check endpoints, ports, groups, lanes, and layout options.
52
+ 3. Create the chart with `createChart(spec)`.
53
+ 4. Use typed commands such as `moveNodes`, `alignNodes`, `snapNodes`, `addEdge`, `toggleGroupCollapse`, `duplicateSelection`, and `pasteSelection` for edits.
54
+ 5. Follow the preview/confirm/commit flow for all business-data changes.
55
+
56
+ ## Implementation Map
57
+
58
+ - Diagram model, validation, layout, and routing: `src/diagram.mjs`
59
+ - Interaction: `src/diagram-interaction.mjs`
60
+ - Diagram Scene: `src/project.mjs`
61
+ - Commands and transactions: `src/command.mjs`, `src/edit-controller.mjs`
62
+ - Editor demo: `playground/diagram-editor.html`
63
+ - Full gallery: `playground/project-gallery.html`
64
+ - Keyboard port connection: Tab focuses nodes/groups/ports, Enter starts or completes a port connection, and Escape cancels it.
65
+
66
+ ## Development Checklist
67
+
68
+ - Update Diagram data rules and `validateDiagram()`.
69
+ - Update command validation and preview/commit/history tests.
70
+ - Ensure edge arrows, labels, and ports are recomputed after node movement.
71
+ - Verify collapsed groups hide member nodes from the rendered Scene while preserving normalized Spec data.
72
+ - Check Canvas and SVG Scene structures together.
73
+ - Update `diagram-editor.html` and the Gallery.
74
+
75
+ ## Acceptance
76
+
77
+ - Edges, arrows, and labels follow nodes after movement.
78
+ - Multi-selection alignment and snapping are visible in state output.
79
+ - Keyboard edits create undoable history entries.
80
+ - Copy/paste preserves internal edges and produces deterministic new IDs.
81
+ - Group collapse hides member nodes and keeps group-level state visible.
82
+ - Groups, ports, and invalid references produce structured validation results.
@@ -0,0 +1,71 @@
1
+ # Editing Contract
2
+
3
+ Safe editing contract for business and Diagram data used by Agents.
4
+
5
+ ## Required Flow
6
+
7
+ ```text
8
+ Read Schema → Build Command → Validate → Preview → Confirm → Commit → ChangeSet
9
+ ```
10
+
11
+ Do not mutate business data objects directly; use the Chart editing API so the Runtime performs validation and history management.
12
+
13
+ ## APIs
14
+
15
+ ```js
16
+ const preview = chart.previewEdit(command);
17
+ if (!preview.valid) return preview.errors;
18
+
19
+ const result = chart.applyEdit(command, {
20
+ preview,
21
+ confirmed: true,
22
+ source: 'agent'
23
+ });
24
+ ```
25
+
26
+ Core APIs:
27
+
28
+ - `getBusinessSchema(name)`
29
+ - `inspectDataSchema(schema)`
30
+ - `validateEdit(command)`
31
+ - `previewEdit(command)`
32
+ - `applyEdit(command, options)`
33
+ - `getChangeSet()`
34
+ - `undo()` / `redo()`
35
+
36
+ ## Command Rules
37
+
38
+ - The command version is currently `1.0`.
39
+ - Targets use stable `id` values; array positions are not business identities.
40
+ - Command validation does not mutate the input command or source data.
41
+ - Host confirmation is required by default; `confirmed: true` is not an authorization system.
42
+ - External persistence, permissions, and authentication belong to the host application.
43
+
44
+ ## Supported Models
45
+
46
+ - `project-task`
47
+ - `timeline-event`
48
+ - `milestone`
49
+ - `burndown-sample`
50
+ - `flow-node`
51
+ - `flow-edge`
52
+ - `swimlane`
53
+
54
+ ## History and Revision
55
+
56
+ Successful commits produce a ChangeSet, audit information, a revision, and an undo history entry. A preview based on an old revision must fail on commit with `STALE_PREVIEW`.
57
+
58
+ ## Implementation Map
59
+
60
+ - Schema: `src/schema.mjs`
61
+ - Commands: `src/command.mjs`
62
+ - Preview/commit: `src/edit.mjs`
63
+ - Transaction lifecycle: `src/edit-controller.mjs`
64
+ - History: `src/history.mjs`
65
+ - Tests: `tests/core.test.mjs`
66
+
67
+ ## Acceptance
68
+
69
+ - Invalid commands do not modify data.
70
+ - Preview and commit commands must match.
71
+ - Confirmation, revisions, audit records, and undo/redo are verifiable.
@@ -0,0 +1,66 @@
1
+ # Frontend Integration
2
+
3
+ Use iChart.js as an ordinary JavaScript UI component inside a browser application. The host application owns data loading, authentication, persistence, routing, and any assistant or natural-language interface.
4
+
5
+ ## Install
6
+
7
+ ```bash
8
+ npm install @taylorwong/ichartjs@^2
9
+ ```
10
+
11
+ For environments without npm registry access, install from GitHub as a fallback: `npm install github:wanghetommy/ichartjs#v2.0.1`.
12
+
13
+ Use the package through a bundler or another environment that resolves npm ESM imports:
14
+
15
+ ```js
16
+ import { createChart } from '@taylorwong/ichartjs';
17
+
18
+ const chart = createChart({
19
+ container: '#chart',
20
+ type: 'bar',
21
+ renderer: 'svg',
22
+ data: { values: rows },
23
+ encoding: {
24
+ x: { field: 'category' },
25
+ y: { field: 'value' }
26
+ },
27
+ interaction: { tooltip: true, keyboard: true },
28
+ accessibility: { enabled: true }
29
+ });
30
+ ```
31
+
32
+ ## Component Lifecycle
33
+
34
+ - Create the chart after the container exists.
35
+ - Call `setData()` when only rows change.
36
+ - Call `update()` when Spec options change.
37
+ - Call `resize()` when the host controls dimensions.
38
+ - Call `destroy()` before replacing the component or removing its container.
39
+
40
+ ## Optional Agent-Assisted UI
41
+
42
+ A host web application may let a user enter an intent such as “show the sales trend.” Keep the integration in JavaScript:
43
+
44
+ 1. Convert application data to JSON-friendly rows.
45
+ 2. Call `inspectData()` and `planChart()` in the browser or Node.js host.
46
+ 3. Build and validate a candidate Spec.
47
+ 4. Render with `createChart()`.
48
+ 5. Show reasons, assumptions, warnings, and unsupported requests in the host UI.
49
+
50
+ If a daily-use assistant cannot execute or generate JavaScript, it cannot directly consume a JavaScript UI component. Its host application must perform the integration; iChart.js does not need a separate service protocol.
51
+
52
+ ## Out of Scope
53
+
54
+ The core package does not provide:
55
+
56
+ - an HTTP service;
57
+ - an MCP server;
58
+ - a command-line application;
59
+ - a Python runtime;
60
+ - file upload, authentication, storage, or sharing infrastructure.
61
+
62
+ Add these only in an application that has a demonstrated requirement. Do not duplicate chart planning or rendering outside the JavaScript runtime.
63
+
64
+ ## Preview
65
+
66
+ Within this repository, run `npm run playground` and open `http://localhost:3000/playground/project-gallery.html` to inspect every public chart type.
@@ -0,0 +1,89 @@
1
+ # Scenario: Project Management
2
+
3
+ Agent usage and development guide for project planning, delivery tracking, and project status reporting.
4
+
5
+ ## Chart Selection
6
+
7
+ | Type | Typical use | Core data |
8
+ | --- | --- | --- |
9
+ | `gantt` | Task schedules, dependencies, critical paths | `id/name/start/end` |
10
+ | `timeline` | Event timelines | `id/title/date` |
11
+ | `milestone` | Key delivery points | `id/title/date` |
12
+ | `burndown` | Remaining Sprint work | `date/remaining` |
13
+
14
+ ## Project Intelligence
15
+
16
+ - Prefer existing primitives for analytics views:
17
+ - `gantt` for schedule variance, baseline vs actual, slack, and critical path
18
+ - `column` for capacity and velocity
19
+ - `area` for cumulative flow
20
+ - `burndown` for release forecasting
21
+ - `scatter` for risk matrix
22
+ - `bar` for issue aging
23
+ - Declare calendar assumptions explicitly with timezone, working weekdays, holidays, and non-working-day policy. Iteration 6 calculations support deterministic `UTC`; other timezone values warn and fall back to `UTC`.
24
+ - Keep derived values separate from source rows. State and tooltips may expose variance, float, warnings, and assumptions, but transforms must not mutate source data.
25
+ - Linked filters and linked selection must use stable record IDs, not array positions.
26
+ - Forecasts, risk scores, and aging buckets are inspectable heuristics. They are not commitments, causal claims, or hidden inference.
27
+
28
+ ## Agent Workflow
29
+
30
+ 1. Confirm the task, event, or Sprint data model.
31
+ 2. Check dates, progress, dependencies, and missing values.
32
+ 3. Select a project chart and create its Spec.
33
+ 4. Validate Gantt dependencies; missing and cyclic dependencies are invalid.
34
+ 5. For intelligence views, surface assumptions, warnings, and linked-filter state in the delivery output.
35
+ 6. Use project tooltips, critical paths, scope changes, forecasts, and variance to explain results.
36
+
37
+ ## Data Rules
38
+
39
+ - Gantt `start` and `end` must be valid dates, and `end` cannot precede `start`.
40
+ - `progress` uses the `0–100` percentage convention.
41
+ - `dependencies` use stable task IDs, either as strings or `{ id, type, lag, lead }` objects, and must form an acyclic graph.
42
+ - Issue aging requires an explicit ISO `today` reference; missing or invalid dates produce warnings instead of guessed buckets.
43
+ - Calendar-aware scheduling may also use dependency objects with explicit `type`, `lag`, and `lead`.
44
+ - `baselineStart`/`baselineEnd` and `actualStart`/`actualEnd` should be treated as explicit source inputs, not inferred values.
45
+ - Burndown `scopeChange` represents scope movement, not completed work.
46
+ - A forecast is an estimate derived from current samples, not a commitment or fact.
47
+ - Capacity warnings, risk quadrants, and aging buckets should stay explainable from source fields.
48
+
49
+ ## Editing
50
+
51
+ Project data edits follow `editing-contract.md`:
52
+
53
+ ```text
54
+ Schema → Command → Validate → Preview → Confirm → Commit → ChangeSet
55
+ ```
56
+
57
+ Typical operations:
58
+
59
+ - `updateProgress`
60
+ - `shiftTask`
61
+ - `addDependency`
62
+ - `removeDependency`
63
+ - `updateMilestone`
64
+
65
+ ## Implementation Map
66
+
67
+ - Project Scenes and tooltips: `src/project.mjs`
68
+ - Project analytics and adapters: `src/project-analytics.mjs`
69
+ - Linked filters and selection helpers: `src/project-linking.mjs`
70
+ - Project schemas: `src/schema.mjs`
71
+ - Commands and editing: `src/command.mjs`, `src/edit.mjs`
72
+ - Tests: `tests/core.test.mjs`
73
+ - Full gallery: `playground/project-gallery.html`
74
+ - Project intelligence demo: `playground/project-intelligence.html`
75
+
76
+ ## Development Checklist
77
+
78
+ - Update project data rules and the Manifest before adding a capability.
79
+ - Add tests for analytics and tooltip content.
80
+ - Cover missing dates, cyclic dependencies, weekends/holidays, lag/lead, scope changes, and insufficient forecast data.
81
+ - Synchronize the Gallery and this guide's limitations.
82
+
83
+ ## Acceptance
84
+
85
+ - All four project chart types initialize in the Gallery.
86
+ - Gantt dependencies, critical-path results, and variance overlays are explainable.
87
+ - Burndown scope changes and forecasts have dedicated tests.
88
+ - Capacity, risk, and aging analytics preserve stable record IDs.
89
+ - Editing commands support preview, commit, undo, and redo.
@@ -0,0 +1,205 @@
1
+ # Agent Quickstart
2
+
3
+ Use this guide when an Agent needs to turn user data or project information into an iChart.js visualization. Use public contracts only; do not inspect renderer or chart implementation files to guess behavior.
4
+
5
+ ## Import Surface
6
+
7
+ ```js
8
+ import {
9
+ createChart,
10
+ getCapabilities,
11
+ getChartCapability,
12
+ inspectData,
13
+ planChart,
14
+ validateSpec
15
+ } from '@taylorwong/ichartjs';
16
+ ```
17
+
18
+ Agents and developers use the same `ichartjs` ESM entry. Agent behavior comes from the public planning APIs and optional Skill, not from a second runtime.
19
+
20
+ Additional package resources:
21
+
22
+ - `ichartjs/capabilities.json`: machine-readable catalog, including per-chart exports, branding, and interaction declarations.
23
+ - `ichartjs/recipes/foundational-analysis`: foundational chart recipes.
24
+ - `ichartjs/recipes/project-management`: project intelligence recipes.
25
+ - `ichartjs/recipes/diagrams/workflow`: diagram editing recipe.
26
+ - `skills/ichartjs/SKILL.md`: optional workflow adapter for Codex, WorkBuddy, and other Agent Skills-compatible hosts.
27
+
28
+ The Skill is not the runtime. Install or register it only when the Agent host supports Skills; it must still call the package's public APIs and capability contract.
29
+
30
+ For coding environments such as Codex, read [Coding Agent Integration](coding-agent-integration.md). For application integration, read [Frontend Integration](frontend-integration.md).
31
+
32
+ ## Standard Workflow
33
+
34
+ ```text
35
+ discover → inspect → plan → build → validate → render → explain, export, self-check
36
+ ```
37
+
38
+ ### 1. Discover
39
+
40
+ Call `getCapabilities()` before choosing a chart. Use `getChartCapability(type)` to verify required roles, interactions, renderers, feature status, exports, and practical limits for a candidate type.
41
+
42
+ ### 2. Inspect
43
+
44
+ Call `inspectData(rows)` and review:
45
+
46
+ - field roles and inferred types;
47
+ - stable identifier fields;
48
+ - dimensions, measures, and temporal coverage;
49
+ - cardinality, missing values, and invalid values;
50
+ - warnings that must remain visible to the user.
51
+
52
+ Inferred roles and units are suggestions. Do not convert them into business facts without user-provided semantics.
53
+
54
+ ### 3. Plan
55
+
56
+ Call `planChart(rows, { intent, renderer })`. Read the full result rather than only `primary`:
57
+
58
+ - `alternatives` and `confidence`;
59
+ - `reasons` and `suggestedEncodings`;
60
+ - `requiredFields`;
61
+ - `assumptions` and `warnings`;
62
+ - `unsupportedRequests` and `nextActions`;
63
+ - the selected per-chart capability profile;
64
+ - `styleRecommendation`, including the resolved preset, mode, palette, reasons, and warnings.
65
+
66
+ Stop before rendering when `requiredFields` is not empty. Ask for the missing information or choose a supported alternative without fabricating data.
67
+
68
+ ### 4. Build a JSON-Friendly Spec
69
+
70
+ For a trend or comparison with one dimension and one or more measures:
71
+
72
+ ```js
73
+ const y = [plan.suggestedEncodings.measure, plan.suggestedEncodings.secondaryMeasure]
74
+ .filter(Boolean)
75
+ .map(field => ({ field, type: 'quantitative' }));
76
+
77
+ const spec = {
78
+ type: plan.primary,
79
+ renderer: 'svg',
80
+ data: { values: rows },
81
+ encoding: {
82
+ x: { field: plan.suggestedEncodings.dimension },
83
+ y: y.length === 1 ? y[0] : y
84
+ },
85
+ interaction: { tooltip: true, hover: true, keyboard: true },
86
+ accessibility: { enabled: true },
87
+ // branding: true is the default; set explicitly branding: false to disable signature + extra bottom padding
88
+ theme: {
89
+ mode: 'auto',
90
+ preset: plan.styleRecommendation.preset,
91
+ palette: plan.styleRecommendation.palette
92
+ }
93
+ };
94
+ ```
95
+
96
+ Use the selected capability and recipes for Pie, Gauge, Heatmap, Radar, project views, and diagrams because their required encodings differ.
97
+
98
+ ### 5. Validate
99
+
100
+ ```js
101
+ const validation = validateSpec(spec);
102
+ if (!validation.valid) {
103
+ return {
104
+ status: 'needs-repair',
105
+ errors: validation.errors,
106
+ warnings: validation.warnings,
107
+ normalizations: validation.normalizations
108
+ };
109
+ }
110
+ ```
111
+
112
+ Do not silently discard diagnostics. Preserve stable `code`, `path`, `message`, `expected`, and `suggestion` fields in Agent output and automated repair loops.
113
+
114
+ ### 6. Render
115
+
116
+ Browser rendering:
117
+
118
+ ```js
119
+ const chart = createChart({ ...validation.spec, container: '#chart' });
120
+ ```
121
+
122
+ Headless planning and scene creation:
123
+
124
+ ```js
125
+ const chart = createChart(validation.spec);
126
+ ```
127
+
128
+ Headless environment capabilities:
129
+ - JSON and SVG string export work with zero dependencies.
130
+ - PNG/JPEG raster export requires the optional `canvas` npm package; otherwise a structured `HEADLESS_EXPORT_UNSUPPORTED` error is returned.
131
+ - The on-screen renderer is decoupled from the export backend; any mounted renderer can export any supported format.
132
+
133
+ ### 7. Explain, Export, and Self-Check
134
+
135
+ ```js
136
+ // JSON export (zero-dependency, all environments)
137
+ const jsonPayload = chart.export({ type: 'json', as: 'object' });
138
+ const jsonString = chart.export({ type: 'json' });
139
+
140
+ // SVG vector export (zero-dependency, browser + headless)
141
+ const svgString = chart.export({ type: 'svg' });
142
+
143
+ // PNG raster (browser always works; headless requires the canvas package)
144
+ const pngDataUrl = typeof document !== 'undefined'
145
+ ? chart.toDataURL('image/png')
146
+ : null;
147
+
148
+ // Browser-only convenience downloads
149
+ if (typeof document !== 'undefined') {
150
+ chart.downloadPNG();
151
+ chart.downloadSVG();
152
+ chart.downloadJSON();
153
+ }
154
+
155
+ const result = {
156
+ plan,
157
+ explanation: chart.explain(),
158
+ state: chart.getState(),
159
+ json: jsonPayload,
160
+ svg: svgString,
161
+ png: pngDataUrl
162
+ };
163
+
164
+ chart.destroy();
165
+ ```
166
+
167
+ Before returning a result, verify:
168
+
169
+ - the selected type exists in capabilities;
170
+ - validation passed;
171
+ - source record IDs remain present in explanation lineage;
172
+ - warnings and assumptions are visible;
173
+ - requested interactions are supported;
174
+ - the branding on/off state is documented so live view and exports stay consistent;
175
+ - the preview URL or output artifact (JSON/SVG/PNG/JPEG) is provided to the user.
176
+
177
+ ## Branding (Signature) Defaults
178
+
179
+ - Default `branding: true`: a low-contrast `Powered by iChart.js` signature appears in the bottom-right corner, synchronized across live rendering, PNG/SVG raster export, and JSON state persistence.
180
+ - Disable explicitly with `branding: false` on the Spec or Theme: the signature text is removed from all surfaces, and the reserved bottom padding is released.
181
+ - Consistency is enforced by a single gate inside `buildScene()`; live view and every export format remain 100% aligned.
182
+
183
+ ## Complete Executable Example
184
+
185
+ Run:
186
+
187
+ ```bash
188
+ npm run example:agent
189
+ ```
190
+
191
+ Read [`../../examples/agent-workflow.mjs`](../../examples/agent-workflow.mjs) for a complete inspect, plan, build, validate, render, explain, export, and destroy workflow.
192
+
193
+ For interactive verification, start `npm run playground` and open `http://localhost:3000/playground/agent-workbench.html`. The top-right Export buttons on every Gallery page exercise the PNG, SVG, and JSON download flows.
194
+
195
+ For visual style selection and live switching, read [Visual Style and Themes](theme-guide.md) and open `http://localhost:3000/playground/theme-gallery.html`.
196
+
197
+ ## Guardrails
198
+
199
+ - Prefer Bar over Pie when category cardinality is high.
200
+ - Require explicit indicator domains for Radar, especially with mixed units.
201
+ - Distinguish missing Heatmap cells from zero values.
202
+ - Do not infer schedule dates, dependencies, working calendars, or forecast confidence.
203
+ - Do not enable interactions that the chart capability does not declare.
204
+ - Do not generate Map or 3D Specs; those types are outside the current contract.
205
+ - Treat structured export errors (valid=false, code=...) as first-class diagnostics; do not silently fall back to a different format.