@taylorwong/ichartjs 2.0.12 → 2.0.14

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 (42) hide show
  1. package/CHANGELOG.md +17 -0
  2. package/README.md +2 -2
  3. package/docs/agent/charting-scenario.md +3 -1
  4. package/docs/agent/coding-agent-integration.md +1 -1
  5. package/docs/agent/development/2.0-release-readiness.md +4 -0
  6. package/docs/agent/development/iteration-13.md +278 -0
  7. package/docs/agent/development/release-sop.md +1 -1
  8. package/docs/agent/development/roadmap.md +2 -1
  9. package/docs/agent/diagram-scenario.md +4 -0
  10. package/docs/agent/editing-contract.md +3 -0
  11. package/docs/agent/frontend-integration.md +1 -1
  12. package/docs/agent/project-scenario.md +3 -0
  13. package/docs/agent/runtime-contract.md +4 -0
  14. package/docs/agent/usage-scenarios.md +1 -1
  15. package/docs/agent/zh-CN/charting-scenario.md +3 -1
  16. package/docs/agent/zh-CN/coding-agent-integration.md +1 -1
  17. package/docs/agent/zh-CN/diagram-scenario.md +17 -1
  18. package/docs/agent/zh-CN/editing-contract.md +2 -0
  19. package/docs/agent/zh-CN/frontend-integration.md +1 -1
  20. package/docs/agent/zh-CN/project-scenario.md +4 -2
  21. package/docs/agent/zh-CN/runtime-contract.md +3 -1
  22. package/docs/agent/zh-CN/usage-scenarios.md +1 -1
  23. package/docs/manifests/capabilities.json +1310 -32
  24. package/docs/manifests/commands.json +7 -7
  25. package/docs/manifests/schemas.json +182 -10
  26. package/package.json +24 -4
  27. package/skills/ichartjs/SKILL.md +1 -1
  28. package/src/capabilities.mjs +10 -36
  29. package/src/chart-lifecycle.mjs +31 -0
  30. package/src/charts.mjs +49 -19
  31. package/src/command.mjs +3 -2
  32. package/src/contract-registry.mjs +59 -0
  33. package/src/diagram.mjs +30 -0
  34. package/src/edit-controller.mjs +1 -1
  35. package/src/errors.mjs +31 -0
  36. package/src/index.mjs +142 -10
  37. package/src/layout.mjs +26 -1
  38. package/src/project.mjs +45 -16
  39. package/src/schema.mjs +1 -0
  40. package/src/spec.mjs +45 -3
  41. package/types/consumer-fixture.ts +35 -0
  42. package/types/index.d.ts +33 -3
package/CHANGELOG.md CHANGED
@@ -1,5 +1,22 @@
1
1
  # Changelog
2
2
 
3
+ ## 2.0.14 - 2026-09-23
4
+
5
+ - Added a canonical contract registry with synchronized runtime capabilities, offline chart profiles, export declarations, command metadata, business models, and Mindmap edge metadata.
6
+ - Added atomic Spec/data/style mutation validation with structured `ChartValidationError` diagnostics, row-complete project validation, deterministic Burndown date warnings, and idempotent chart destruction.
7
+ - Added complete public Chart declarations, a strict TypeScript consumer fixture, module-cycle checks, executable Agent workflow checks, focused Iteration 13 regression tests, and package dry-run verification.
8
+ - Fixed horizontal Bar y-axis titles so they use the shared vertical, centered layout with reserved left-side space instead of a narrow top-left truncation path.
9
+
10
+ ## 2.0.13 - 2026-09-22
11
+
12
+ - Made legend, axis, and project-label layout Unicode-aware, added collision-safe y-axis titles, and restored right-axis title rendering.
13
+ - Simplified clear forward Gantt dependencies to three segments while preserving typed dependency endpoints and safe fallback routing.
14
+ - Arranged automatic Architecture nodes horizontally within layers, preserved explicit positions, and added Node plus Chrome layout regression coverage.
15
+
16
+ ## 2.0.12 - 2026-09-21
17
+
18
+ - Fixed Bar charts so `xAxis.title` and `yAxis.title` render through the dedicated horizontal-bar axis branch.
19
+
3
20
  ## 2.0.11 - 2026-09-21
4
21
 
5
22
  - Improved promotional chart composition by expanding the internal plotting areas for trend, delivery, and architecture examples without enlarging their cards.
package/README.md CHANGED
@@ -44,7 +44,7 @@ getCapabilities
44
44
  npm install @taylorwong/ichartjs@^2
45
45
  ```
46
46
 
47
- As a fallback for environments without npm access, install directly from GitHub: `npm install github:wanghetommy/ichartjs#v2.0.11`.
47
+ As a fallback for environments without npm access, install directly from GitHub: `npm install github:wanghetommy/ichartjs#v2.0.14`.
48
48
 
49
49
  ### Optional Agent Skill
50
50
 
@@ -66,7 +66,7 @@ For a non-interactive global Codex installation:
66
66
  npx skills add wanghetommy/ichartjs --skill ichartjs --agent codex --global --yes
67
67
  ```
68
68
 
69
- For a release-pinned installation, use `npx skills add https://github.com/wanghetommy/ichartjs/tree/v2.0.11/skills/ichartjs --agent codex --global --yes`. WorkBuddy users can import the same tagged `skills/ichartjs` URL through the host's Skill interface; do not assume a `--agent workbuddy` adapter unless the installed CLI declares it. Package consumers can still copy `node_modules/@taylorwong/ichartjs/skills/ichartjs` as a manual fallback. After installation, invoke `$ichartjs` when named Skill invocation is supported, or select `ichartjs` in the host UI.
69
+ For a release-pinned installation, use `npx skills add https://github.com/wanghetommy/ichartjs/tree/v2.0.14/skills/ichartjs --agent codex --global --yes`. WorkBuddy users can import the same tagged `skills/ichartjs` URL through the host's Skill interface; do not assume a `--agent workbuddy` adapter unless the installed CLI declares it. Package consumers can still copy `node_modules/@taylorwong/ichartjs/skills/ichartjs` as a manual fallback. After installation, invoke `$ichartjs` when named Skill invocation is supported, or select `ichartjs` in the host UI.
70
70
 
71
71
  ### Agent workflow
72
72
 
@@ -35,13 +35,15 @@ Agent usage and development guide for generic data analysis and metric visualiza
35
35
  | Axis title and format | `xAxis.title/format`, `yAxis.title/format` | Line, Area, Bar, Column, Scatter |
36
36
  | Readable numeric domain | `yAxis.nice`, `yAxis.ticks`, `yAxis.domain` | Line, Area, Bar, Column, Scatter |
37
37
  | Data labels | `labels.enabled/format` | Charts that declare `labels` in capabilities |
38
- | Legend | `legend.visible/position` | Multi-series Cartesian, Pie, and Radar |
38
+ | Legend | `legend.visible` | Multi-series Cartesian, Pie, and Radar |
39
39
  | Gauge domain | `domain: [min, max]` | Gauge |
40
40
  | Heatmap color domain | `colorScale.domain` | Heatmap |
41
41
  | Radar indicator domain | `indicators[].min/max` | Radar |
42
42
 
43
43
  Do not put `title`, `format`, `labels`, or `legend` under `encoding`; `validateSpec()` reports those placements as warnings. Numeric y-axes use readable domains by default (`nice: true`, `ticks: "auto"`). Use `yAxis.domain: [min, max]` for an explicit range, or `yAxis.nice: false` to retain the raw boundary. `xAxis.min/max` and `xAxis.domain` are unsupported for categorical/time layouts and produce a structured warning.
44
44
 
45
+ Layout is deterministic and renderer-independent. Legend items use Unicode-aware text estimates for spacing and automatically wrap when a row is full; a single label that cannot fit is truncated and reports `LEGEND_OVERFLOW`. Y-axis titles are centered beside their tick columns; Bar also places its categorical y-axis title vertically and centered on the left, with space reserved before the plot rectangle. If the chart is physically too short for a title, the renderer truncates it and reports `TITLE_TRUNCATED`. Axis and project-label reserves are computed before the plot rectangle, so Canvas, SVG, headless rendering, and exports share the same geometry.
46
+
45
47
  ## Encoding Contracts
46
48
 
47
49
  Use only the channels declared for the selected chart: Cartesian charts use `encoding.x` and `encoding.y`; Pie and Funnel use `encoding.category` and `encoding.value`; Gauge uses only `encoding.value`; Heatmap uses `encoding.x`, `encoding.y`, and `encoding.color`; Radar uses `indicators[].field`. `validateSpec()` reports `UNSUPPORTED_ENCODING_CHANNEL` for an unused channel and `MISSING_ENCODING_FIELD` when a referenced field is absent. Gauge additionally requires `domain: [min, max]`; values outside the domain are clamped for the rendered arc and report `VALUE_CLAMPED`. Pie reports `NEGATIVE_VALUE_DROPPED` instead of silently treating negative values as valid shares, and reports `ZERO_TOTAL` for an empty result.
@@ -33,7 +33,7 @@ Install the official Skill with the standard Agent Skills CLI:
33
33
  npx skills add wanghetommy/ichartjs --skill ichartjs
34
34
  ```
35
35
 
36
- For global non-interactive Codex setup, append `--agent codex --global --yes`. To pin the released workflow, install `https://github.com/wanghetommy/ichartjs/tree/v2.0.11/skills/ichartjs`. WorkBuddy can import that tagged directory through its Skill interface; only use a host-specific `--agent` value when the installed CLI declares it.
36
+ For global non-interactive Codex setup, append `--agent codex --global --yes`. To pin the released workflow, install `https://github.com/wanghetommy/ichartjs/tree/v2.0.14/skills/ichartjs`. WorkBuddy can import that tagged directory through its Skill interface; only use a host-specific `--agent` value when the installed CLI declares it.
37
37
 
38
38
  Verify discovery with `npx skills add wanghetommy/ichartjs --list`; the result should include `ichartjs`.
39
39
 
@@ -38,6 +38,10 @@ iChart.js 2.0 is a new Agent-first product line. Compatibility with 1.x and a 1.
38
38
  1. **Final commit and tag.** Commit the consistent `2.0.0` package, runtime, Playground, documentation, and changelog versions, then create `v2.0.0` from that exact commit.
39
39
  2. **Default branch cutover.** GitHub still uses `master`, which currently points to the archived 1.x project and its legacy development dependencies. Fast-forward `master` to the final 2.0 commit before creating the GitHub Release.
40
40
 
41
+ ## Iteration 13 Addendum — 2026-09-23
42
+
43
+ The historical 2.0.0 release decision remains unchanged. Release `v2.0.14` includes Iteration 13 contract hardening without adding a chart type: 18 chart profiles, 25 commands, 11 schemas, contract version `1.1`, atomic mutation validation, Mindmap edge discovery, strict TypeScript consumer compilation, no active source cycles, 96 Node tests, Chromium browser acceptance, and package dry-run verification. It also corrects Bar y-axis title layout and exposes `TITLE_TRUNCATED` when physical chart height forces truncation.
44
+
41
45
  ## Deferred npm Publication
42
46
 
43
47
  The public npm name `ichartjs` currently resolves to an npm security holding package, and this machine has no authenticated publisher. Per the release decision, npm publication is deferred and does not block the GitHub source release.
@@ -0,0 +1,278 @@
1
+ # Iteration 13 — Contract-Driven Runtime and Agent Reliability
2
+
3
+ Iteration 13 hardens the architecture that now supports 18 public chart types, 25 edit commands, 11 business schemas, two renderers, project analytics, diagram editing, themes, preferences, and export. It adds no chart type and does not redesign the visual language. The goal is to make every public capability derive from one contract, make every mutation pass the same validation boundary, and make Agent guidance executable rather than advisory.
4
+
5
+ ## Review Baseline
6
+
7
+ The plan is based on a repository-wide review of the runtime, Agent documentation, manifests, TypeScript declarations, tests, Playground, and package output at `v2.0.13`.
8
+
9
+ - `npm run agent:check` passes with 95 tests, 18 chart types, 25 commands, and 11 schemas.
10
+ - `npm run test:browser` passes its current Chrome layout scenario.
11
+ - `npm pack --dry-run --json` succeeds with 90 package entries.
12
+ - The dual-renderer, single-Scene-Graph architecture remains the correct foundation.
13
+ - The main risks are contract drift and concentration of responsibilities, not a lack of chart types.
14
+
15
+ ## Review Findings
16
+
17
+ | Priority | Finding | Evidence | Iteration 13 response |
18
+ | --- | --- | --- | --- |
19
+ | P0 | Construction validates a Spec, but `Chart#update()` and `Chart#setData()` normalize and render without running the same validation. Invalid post-construction state can therefore become live. | `src/index.mjs` constructor versus `update()` and `setData()` | Add one transactional prepare/validate/commit pipeline for creation and mutation. |
20
+ | P0 | Project validation is not consistently row-complete. Gantt, Timeline, and Milestone accept rows missing required dates when another row has a date, and Burndown does not reject invalid dates at the Spec boundary. | `src/spec.mjs` project validation branch | Add chart-family row contracts and precise per-row diagnostics. |
21
+ | P0 | Runtime capabilities, JSON manifests, command/schema metadata, TypeScript declarations, and prose are manually mirrored. Existing checks compare only selected lists and fields. | `src/capabilities.mjs`, `src/index.mjs`, `docs/manifests/`, `types/index.d.ts`, `scripts/check-agent-docs.mjs` | Establish a canonical registry and generate or structurally verify every public projection. |
22
+ | P1 | The runtime supports JPEG through the detailed export contract while the summary export list omits it; the packaged capability manifest points to per-chart profiles but does not contain them. | `getCapabilities().exports`, `getCapabilities().export.types`, `docs/manifests/capabilities.json` | Define one export capability shape and publish complete offline profiles. |
23
+ | P1 | The `Chart` runtime exposes event, inspection, selection, clipboard, diagram, plugin, and low-level methods that are missing from the declared `Chart` interface. There is no TypeScript consumer compilation gate. | `src/index.mjs` and `types/index.d.ts` | Define the supported public surface explicitly and compile representative consumers in CI. |
24
+ | P1 | Mindmap edge editing reuses the Flow edge schema internally, but command capability metadata does not represent Mindmap edges even though Iteration 12 promises a shared diagram edge-editing contract. | `src/edit.mjs`, `src/command.mjs`, `docs/manifests/commands.json` | Introduce an explicit shared diagram-edge model or a declared Mindmap edge model and align edit discovery. |
25
+ | P1 | `src/index.mjs`, chart/project scene construction, and `tests/core.test.mjs` contain many unrelated responsibilities. This raises regression scope and makes ownership boundaries harder for Agents to infer. | Runtime and test module sizes and imports | Extract cohesive runtime controllers and split tests by contract and chart family without changing the root import. |
26
+ | P1 | Agent documentation checks prove presence, links, and selected identifiers, but do not execute examples, validate English/Chinese contract parity, or ensure Skill selection guidance covers all public types. | `scripts/check-agent-docs.mjs`, `skills/ichartjs/references/chart-selection.md` | Add executable documentation fixtures, semantic parity checks, and complete Skill routing coverage. |
27
+
28
+ ## Architectural Intent
29
+
30
+ The root package remains a single ESM entry. Internal decomposition must not create competing runtimes or renderer-specific business logic.
31
+
32
+ ```mermaid
33
+ flowchart LR
34
+ A[Canonical contract registry] --> B[Runtime capability API]
35
+ A --> C[JSON manifests]
36
+ A --> D[Type declarations]
37
+ A --> E[Agent docs and Skill fixtures]
38
+ B --> F[Spec planning and validation]
39
+ C --> F
40
+ D --> G[TypeScript consumer checks]
41
+ E --> H[Executable documentation checks]
42
+ F --> I[Chart runtime]
43
+ G --> J[Release gate]
44
+ H --> J
45
+ I --> J
46
+ style A fill:#bbdefb,color:#0d47a1
47
+ style F fill:#fff3e0,color:#e65100
48
+ style I fill:#c8e6c9,color:#1a5e20
49
+ style J fill:#f3e5f5,color:#7b1fa2
50
+ ```
51
+
52
+ All state-changing APIs use the same transaction boundary:
53
+
54
+ ```mermaid
55
+ sequenceDiagram
56
+ participant Host
57
+ participant Chart
58
+ participant Contract as Validation Contract
59
+ participant Scene as Scene Builder
60
+ participant Renderer
61
+ Host->>Chart: create / update / setData / applyEdit
62
+ Chart->>Contract: normalize candidate and validate
63
+ alt invalid candidate
64
+ Contract-->>Chart: structured diagnostics
65
+ Chart-->>Host: reject; retain previous Spec and Scene
66
+ else valid candidate
67
+ Contract-->>Chart: normalized immutable candidate
68
+ Chart->>Scene: build next Scene Graph
69
+ Scene-->>Chart: model and state
70
+ Chart->>Renderer: commit render
71
+ Chart-->>Host: emit one committed change
72
+ end
73
+ ```
74
+
75
+ ## Design Rules
76
+
77
+ - Keep `@taylorwong/ichartjs` as the only runtime entry point.
78
+ - Preserve the single normalized Spec and Scene Graph shared by Canvas, SVG, headless export, and browser export.
79
+ - Keep chart selection, validation, capabilities, manifests, types, recipes, and docs consistent by construction.
80
+ - Reject invalid state before mutating the live chart; failed changes leave Spec, Scene, selection, history, and revision unchanged.
81
+ - Keep interaction and editing disabled by default unless the host enables them explicitly.
82
+ - Keep public behavior backward compatible unless the current behavior violates a documented validation or safety invariant.
83
+ - Prefer internal modules with one responsibility over new package-level subpaths.
84
+ - Do not add a runtime dependency solely for code generation or validation.
85
+
86
+ ## Review Adjustments — Reliability Requirements Added
87
+
88
+ The initial plan is sound, but the following requirements are part of Iteration 13 rather than optional follow-up work. They close the remaining gaps between a structurally consistent API and a runtime that an Agent can safely operate.
89
+
90
+ ### Mutation and error contract
91
+
92
+ - Successful `update()` and `setData()` remain chainable and return `this`; invalid mutations throw one documented `ChartValidationError` with stable `code`, `details`, `path`, `expected`, `received`, and `suggestion` fields.
93
+ - `applyEdit()` keeps its existing `{ valid, errors }` result contract so edit preview/commit flows do not change shape.
94
+ - A failed mutation emits no change event, does not invalidate history, does not change selection or revision, and does not replace the previous rendered output.
95
+ - `setTheme()` and `setPreferences()` use the same style preparation boundary; `applyPatch()` is either routed through validation or explicitly marked advanced and excluded from the safe mutation guarantee.
96
+ - Plugin installation and renderer replacement must declare whether they are transactional. If they cannot roll back external side effects, they must return a structured failure and be excluded from the atomic mutation claim.
97
+
98
+ ### Determinism, safety, and observability
99
+
100
+ - Add a separate `contractVersion`, independent of the package semver. Additive contract fields preserve the version; removed, renamed, or reinterpreted fields require a version change and release note.
101
+ - Use explicit policies for stable IDs, duplicate IDs, ISO-8601 dates, date-only values, time zones, duplicate Burndown dates, ordering, locale, rounding, and generated fallback IDs. Fallback IDs are allowed only for read-only visualization and must produce a warning.
102
+ - Define capability limits for rows, nodes, edges, recursion depth, and export size. Exceeding a limit must produce a deterministic diagnostic rather than a browser hang or uncontrolled memory growth.
103
+ - Verify that SVG text, labels, titles, and diagram content are emitted as text-safe values and cannot become executable markup. Canvas and SVG must expose equivalent semantic text and data references.
104
+ - Give every diagnostic a stable code and severity, and document whether it is an error, warning, normalization, or unsupported-option notice. Agent-facing diagnostics must remain locale-aware without changing their codes.
105
+ - Make lifecycle guarantees explicit: `destroy()` is idempotent, failed render preparation releases temporary resources, and listeners, observers, tooltips, and plugins do not leak after destroy.
106
+
107
+ ### Projection and release evidence
108
+
109
+ - The JavaScript registry is the runtime source of truth; manifests are generated or compared from a normalized JSON-safe projection, not deep-compared against objects containing functions or implementation details.
110
+ - Runtime version synchronization is checked by release tooling against `package.json`; the browser runtime does not dynamically depend on Node-only package metadata.
111
+ - Every release candidate records the contract version, package version, manifest checksum, package entry import, JSON subpath import, recipe import, TypeScript consumer result, and expected unsupported export results.
112
+
113
+ ## 13A — Canonical Public Contract Registry
114
+
115
+ 1. Add a canonical, JSON-safe registry for chart types, families, required data roles, encoding channels, features, interactions, renderers, exports, limits, business models, edit operations, and preference fields.
116
+ 2. Make `getCapabilities()`, `getChartCapability()`, `validateSpec()`, command discovery, and schema discovery consume that registry instead of repeating lists.
117
+ 3. Generate `docs/manifests/capabilities.json`, `commands.json`, and `schemas.json` from the registry, or make a deterministic check compare their complete structures.
118
+ 4. Include complete per-chart profiles in the packaged capability manifest so an offline Agent does not need to inspect source code.
119
+ 5. Replace the ambiguous top-level `exports` summary with one canonical export list that includes PNG, JPEG, SVG, and JSON consistently.
120
+ 6. Declare a shared `diagram-edge` contract or explicit Flow, Architecture, and Mindmap edge models with identical supported edit operations where behavior is shared.
121
+ 7. Add stable contract versioning rules: additive fields retain the current contract version; removed or reinterpreted fields require a version change and migration note.
122
+ 8. Keep runtime version metadata sourced from package metadata during release checks rather than requiring unrelated hand-edited literals.
123
+
124
+ ### 13A Checkpoint
125
+
126
+ - Changing a chart type, command, schema, interaction, export, or preference in one registry updates or fails every dependent projection.
127
+ - `getCapabilities()` and the packaged JSON manifest are deep-equal for their shared contract.
128
+ - Every chart profile is available without executing the runtime.
129
+ - Mindmap edge operations are discoverable and match actual preview/commit behavior.
130
+
131
+ ## 13B — Transactional Validation and Data Integrity
132
+
133
+ 1. Extract a shared `prepareSpec(candidate)` path that performs normalization, validation, theme/preference resolution, and diagnostic collection before commit.
134
+ 2. Route the constructor, `update()`, `setData()`, renderer changes, and accepted edit results through the same preparation boundary.
135
+ 3. Make failed updates atomic: do not change the live Spec, renderer, Scene, history, selection, revision, subscriptions, or emitted change events.
136
+ 4. Preserve the current constructor error shape and define the `ChartValidationError` mutation failure contract described above.
137
+ 5. Validate every Gantt row for stable ID, start, end, valid interval, dependency references, and declared dependency semantics.
138
+ 6. Validate every Timeline and Milestone row for stable ID, label/title, and valid ISO-8601 date.
139
+ 7. Validate every Burndown row for valid date and finite remaining work; validate ordering and duplicate-date policy explicitly.
140
+ 8. Reuse business schema rules where possible so Spec validation and edit validation do not disagree.
141
+ 9. Add immutable-input tests for creation, update, data replacement, failed validation, edit commit, undo, and redo.
142
+ 10. Preserve warnings and normalizations across updates instead of retaining stale constructor diagnostics.
143
+
144
+ ### 13B Checkpoint
145
+
146
+ - An invalid update returns structured diagnostics and leaves `chart.getSpec()`, `getState()`, revision, and rendered output unchanged.
147
+ - Project charts reject invalid rows with exact paths such as `data.values[3].start`.
148
+ - Constructor, update, and data replacement agree on validity for the same candidate Spec.
149
+ - Valid existing Specs and recipes produce unchanged normalized output and Scene snapshots.
150
+
151
+ ## 13C — Runtime Boundary Refactoring
152
+
153
+ 1. Reduce `src/index.mjs` to public composition and exports by extracting lifecycle, event binding, accessibility, selection, export, and download responsibilities into focused internal modules. Freeze the supported public method allowlist before extraction; do not infer public API from every current class method.
154
+ 2. Extract headless/browser export serialization from the `Chart` class while preserving all current method signatures and output representations.
155
+ 3. Separate generic chart-family scene builders from shared chrome layout:
156
+ - Cartesian marks and axes.
157
+ - Part-to-whole, stage, and indicator marks.
158
+ - Matrix and radial marks.
159
+ - Shared title, legend, label, branding, and diagnostic layout.
160
+ 4. Keep project chart scene construction separate from diagram scene construction; both continue to return the same Scene Graph contract.
161
+ 5. Move renderer-independent interaction state transitions out of DOM event wiring so they can be tested headlessly.
162
+ 6. Define internal dependency direction as contracts/data → validation/layout → scene builders → runtime controllers → public entry.
163
+ 7. Add a cycle check for active `src/` modules.
164
+ 8. Keep each extraction behavior-preserving and land it with focused parity tests before removing the old implementation. Large scene-builder moves are optional for the first Iteration 13 release and must not block the contract and transaction work.
165
+
166
+ ### 13C Checkpoint
167
+
168
+ - The public root exports and `iChart` compatibility object remain unchanged except for documented contract corrections.
169
+ - Canvas, SVG, and headless SVG consume equivalent Scene Graphs before and after extraction.
170
+ - No active source module has a circular dependency.
171
+ - Lifecycle, export, interaction, and chart-family tests can run independently.
172
+
173
+ ## 13D — Complete Types and Executable Agent Guidance
174
+
175
+ 1. Define an explicit supported `Chart` API allowlist and add declarations for events, plugins, data inspection, selected data, data tables, diagram collections, clipboard operations, connection operations, group collapse, hit testing, and box selection. Do not automatically declare every internal method found on the class.
176
+ 2. Mark low-level APIs such as `applyPatch()` explicitly as advanced or deprecated if they cannot uphold the transactional contract.
177
+ 3. Replace broad `Record<string, unknown>` return values with named result, state, event, diagnostic, selection, and edit interfaces where the runtime shape is stable.
178
+ 4. Add TypeScript consumer fixtures for generic charts, project analytics, diagram editing, preferences, events, and every export representation.
179
+ 5. Add an API reference generated from or verified against runtime exports and TypeScript declarations.
180
+ 6. Convert canonical Quickstart, Runtime Contract, Editing Contract, and Skill examples into executable fixtures using local package imports.
181
+ 7. Add stable section IDs or contract markers to English and Chinese guides, then check required sections, API names, warning codes, and examples in both languages.
182
+ 8. Complete Skill chart selection for Architecture and Mindmap and ensure every public chart type maps to at least one supported intent and guardrail.
183
+ 9. Keep English as the canonical technical contract and Chinese as an equivalent companion, without requiring literal sentence-by-sentence translation.
184
+
185
+ ### 13D Checkpoint
186
+
187
+ - A representative TypeScript consumer compiles with no local declaration patches.
188
+ - Every documented public `Chart` method exists at runtime and in `types/index.d.ts`.
189
+ - Canonical documentation code blocks execute or are explicitly marked illustrative.
190
+ - English and Chinese guides expose the same required contract sections and identifiers.
191
+ - The official Skill can route all 18 public chart types using only packaged references and manifests.
192
+
193
+ ## 13E — Test Architecture and Release Evidence
194
+
195
+ 1. Split the monolithic core test into focused suites for Spec/data, capabilities/contracts, generic charts, project charts, diagrams, editing/history, preferences/themes, exports, lifecycle, and package consumers.
196
+ 2. Keep shared fixtures for all chart types, renderers, project rows, diagram entities, and diagnostics to avoid diverging test data.
197
+ 3. Add contract matrix tests covering every chart type × renderer × export declaration without requiring every combination to use a browser; unsupported combinations must assert their documented structured failure rather than being treated as test omissions.
198
+ 4. Expand browser coverage beyond layout to one end-to-end path each for generic interaction, project inspection, diagram editing, preferences, accessibility, and export.
199
+ 5. Add mutation rollback tests for invalid update, invalid data replacement, stale edit, failed renderer switch, plugin failure, event suppression, revision stability, and idempotent destroy.
200
+ 6. Add manifest regeneration/diff checks, TypeScript compilation, documentation examples, module-cycle checks, and package-consumer tests to CI.
201
+ 7. Keep Node 18, 20, and 22 coverage; run browser acceptance once on the primary CI Node version.
202
+ 8. Record physical-device touch and release-host performance as environment evidence, not as claims inferred from desktop automation.
203
+
204
+ ### 13E Checkpoint
205
+
206
+ - A failure identifies one contract or feature suite instead of only `tests/core.test.mjs`.
207
+ - Browser CI exercises behavior, not only geometry.
208
+ - `npm run agent:check` includes contract, type, docs-example, syntax, and core test gates.
209
+ - `npm run test:browser` covers the maintained critical workflows with no uncaught errors.
210
+ - `npm pack --dry-run` contains synchronized manifests, types, Agent guides, Skill references, recipes, and examples.
211
+
212
+ ## Execution Order
213
+
214
+ 1. Freeze the mutation error contract, public API allowlist, contract version, and stable-ID policy before implementation.
215
+ 2. Land 13A first so later work consumes one authoritative contract.
216
+ 3. Implement 13B before refactoring runtime classes; lock current valid behavior with mutation, project-data, determinism, and safety tests.
217
+ 4. Complete 13D against the stabilized registry and public API allowlist.
218
+ 5. Execute 13C as small behavior-preserving extractions with parity checks after each move; defer large scene-builder moves if they threaten the release gate.
219
+ 6. Promote 13E checks continuously after each phase, then record final acceptance evidence.
220
+
221
+ Each phase must be independently releasable. Do not combine a behavior correction and a large file move in the same change unless tests prove the old and new paths are equivalent.
222
+
223
+ ## Non-Goals
224
+
225
+ - No new public chart type.
226
+ - No Map, 3D, Fishbone, Organization Chart, Kanban, or collaborative multi-user editing.
227
+ - No second runtime entry and no framework-specific wrapper.
228
+ - No renderer-specific Spec or edit contract.
229
+ - No visual redesign of existing charts, themes, or Playground pages.
230
+ - No mandatory server, database, AI provider, or native Canvas dependency.
231
+ - No claim of semantic translation quality based only on file presence or matching line counts.
232
+
233
+ ## Acceptance Matrix
234
+
235
+ | Area | Required evidence |
236
+ | --- | --- |
237
+ | Architecture | No active module cycles; root entry remains stable; extracted controllers pass parity tests. |
238
+ | Contracts | Runtime capabilities, manifests, commands, schemas, preferences, and exports match the canonical registry. |
239
+ | Functionality | Invalid mutations roll back; project rows validate individually; existing valid output remains compatible. |
240
+ | Agent | Offline manifest includes complete profiles; planning, validation, explanation, and Skill routing agree. |
241
+ | Types | TypeScript fixtures compile for lifecycle, events, editing, diagrams, preferences, and exports. |
242
+ | Documentation | Canonical examples execute; local links resolve; English/Chinese contract markers match. |
243
+ | Rendering | Canvas/SVG Scene semantics and headless SVG export remain equivalent. |
244
+ | Browser | Generic, project, diagram, preferences, accessibility, and export workflows pass in maintained browser tests. |
245
+ | Packaging | ESM import, JSON subpaths, recipes, declarations, Skill files, and dry-run tarball checks pass. |
246
+
247
+ ## Verification Commands
248
+
249
+ - `npm run agent:check`
250
+ - `npm run test:browser`
251
+ - `npm run example:agent`
252
+ - `npm pack --dry-run`
253
+ - `git diff --check`
254
+
255
+ The implementation may add focused scripts such as `contracts:check`, `types:check`, `docs:examples`, and `deps:check`; `agent:check` must invoke the non-browser gates so local and CI behavior stay aligned.
256
+
257
+ ## Deliverables
258
+
259
+ - Canonical public contract registry and deterministic manifest generation/checking.
260
+ - Transactional Spec/data mutation pipeline with row-complete project validation.
261
+ - Focused runtime controllers and chart-family scene modules behind the unchanged root entry.
262
+ - Complete public TypeScript surface and compiled consumer fixtures.
263
+ - Executable Agent documentation checks and bilingual semantic parity markers.
264
+ - Complete Architecture/Mindmap Skill routing and diagram-edge capability metadata.
265
+ - Split unit/contract suites and expanded critical browser workflows.
266
+ - Updated `roadmap.md`, Agent guides, manifests, Skill references, changelog, and acceptance record.
267
+
268
+ ## Implementation Evidence
269
+
270
+ - Contract source: `src/contract-registry.mjs`; generated projection: `docs/manifests/capabilities.json`; synchronized checks: `npm run contracts:check`.
271
+ - Mutation safety: `ChartValidationError`, atomic `update()`/`setData()`/`setTheme()`/preference/patch paths, project row diagnostics, duplicate/out-of-order Burndown warnings, and idempotent `destroy()`.
272
+ - Diagram contract: explicit `mindmap-edge` schema and command discovery aligned with Flow and Architecture edge operations.
273
+ - Agent/type gates: `npm run types:check` compiles `types/consumer-fixture.ts` with TypeScript 5.9; `npm run docs:examples` completes the packaged Agent workflow; `npm run deps:check` reports no source cycles.
274
+ - Acceptance: 95 Node tests, maintained Chromium browser workflow, `git diff --check`, and `npm pack --dry-run` with 94 files passed. The npm dry-run uses a temporary cache to avoid unrelated root-owned cache files.
275
+
276
+ ## Completion Definition
277
+
278
+ Iteration 13 is complete when one authoritative contract drives runtime discovery and packaged metadata; every chart mutation is validated and atomic; the public TypeScript surface matches the supported runtime; Agent examples and bilingual contract markers are mechanically checked; internal runtime responsibilities are separated without changing valid output; and all automated, browser, package, and documentation gates pass. New chart types remain deferred until this foundation is complete.
@@ -16,7 +16,7 @@
16
16
  1. `npm run check` → exit 0
17
17
  2. `npm test` → exit 0 (all current tests pass)
18
18
  3. `npm run docs:check` → exit 0
19
- 4. `npm run agent:check` → exit 0
19
+ 4. `npm run agent:check` and `npm run test:browser` → both exit 0 (`test:browser` requires Chrome or `CHROME_BIN`)
20
20
  5. `npm whoami` → output = `taylorwong`
21
21
  6. `npm config get registry` → output = `https://registry.npmjs.org/`
22
22
 
@@ -1,6 +1,6 @@
1
1
  # iChart.js 2.0 Roadmap
2
2
 
3
- > Roadmap baseline: 2026-09-14. Current release status: `v2.0.11` includes the completed Iteration 12 structured-diagram work, follow-up chart/menu fixes, hardened Agent chart contracts, and architecture/promo layout fixes. Geographic charts and 3D rendering remain out of scope until explicitly reintroduced.
3
+ > Roadmap baseline: 2026-09-14. Current release status: `v2.0.14` includes the completed Iteration 12 structured-diagram work, Iteration 13 contract hardening, and the Bar y-axis title layout fix. Geographic charts and 3D rendering remain out of scope until explicitly reintroduced.
4
4
 
5
5
  ## Current Status
6
6
 
@@ -15,6 +15,7 @@
15
15
  - Iteration 10A Export Contract Hardening was implemented and released in `v2.0.5`: export representations and type errors are deterministic, optional Node raster export uses `exportAsync()`, Canvas/SVG paint semantics are aligned, and the playground server has safer port/path handling. No chart behavior or public chart type was added.
16
16
  - Iteration 11 visual preference controls are included in the `v2.0.6` release: compact per-chart settings, capability-aware visibility controls, theme-aware icon contrast, explicit font-size defaults, shared page preferences, and Agent-adjustable global settings.
17
17
  - Iteration 12A–12G is included in `v2.0.7`: shared structured-diagram contracts, Architecture layers/boundaries, Mindmap parent-child tree/radial layouts with true cubic-Bezier edges, Agent schemas/capabilities, renderer-parity edge hit testing and selection, waypoint/segment handles, persistent manual routing, and Gallery/documentation coverage. Navigation and editing remain disabled by default and require explicit host activation.
18
+ - Iteration 13A–13E is complete and included in `v2.0.14`: canonical contract registry and generated capability projection, atomic Spec/data/style mutations, row-complete project validation, explicit Mindmap edge metadata, complete public TypeScript declarations and consumer fixture, module-cycle and documentation/example gates, browser acceptance, and package dry-run evidence. No chart type was added.
18
19
  - The original `2.0.0` readiness record is historical and superseded by the published `2.0.x` releases. Current release checks are defined by `docs/agent/development/release-sop.md`.
19
20
 
20
21
  ## Iteration 4 — Agent Data Contract and Business Editing
@@ -11,6 +11,8 @@ Agent usage and development guide for process modeling, responsibility mapping,
11
11
 
12
12
  Architecture and mindmap are both structured diagrams, but they are not interchangeable: architecture describes declared domain or system relationships, while a mindmap describes an idea hierarchy.
13
13
 
14
+ Architecture layers are horizontal bands ordered from top to bottom. Automatic layout places nodes in the same layer left to right on a shared row, then adds another row only when the available width cannot hold the layer. An explicit `node.position` remains authoritative, including after editing; automatic layout never rewrites the Spec.
15
+
14
16
  ## Data Model
15
17
 
16
18
  ```js
@@ -71,6 +73,7 @@ Current limitations:
71
73
  - `deleteGroup` defaults to `ungroup`; use `delete-members` only after explicit host confirmation.
72
74
  - Canvas keeps basic accessibility text, while SVG exposes richer diagram semantics.
73
75
  - Cross-browser matrix and physical-device validation remain acceptance work, not runtime guarantees.
76
+ - Mixed manual and automatic Architecture positions can overlap; explicit positions are preserved rather than silently moved.
74
77
 
75
78
  ## Agent Workflow
76
79
 
@@ -107,4 +110,5 @@ Current limitations:
107
110
  - Copy/paste preserves internal edges and produces deterministic new IDs.
108
111
  - Group collapse hides member nodes and keeps group-level state visible.
109
112
  - Groups, ports, and invalid references produce structured validation results.
113
+ - Architecture nodes without explicit positions are arranged horizontally within their declared layer; explicit positions survive rendering and editing.
110
114
  - Canvas and SVG produce equivalent edge selection, handle dragging, persisted waypoints, keyboard behavior, and exports.
@@ -54,10 +54,13 @@ Core APIs:
54
54
  - `swimlane`
55
55
  - `architecture-node`
56
56
  - `architecture-edge`
57
+ - `mindmap-edge`
57
58
  - `mindmap-node`
58
59
 
59
60
  ## History and Revision
60
61
 
62
+ Spec/data mutations use the same atomic boundary as edits. Catch `ChartValidationError` for invalid `update()`, `setData()`, `setTheme()`, or preference input; the failed call emits no committed change and does not advance the revision.
63
+
61
64
  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`.
62
65
 
63
66
  ## Implementation Map
@@ -10,7 +10,7 @@ This is the production component path. For one-off files or Agent-led repository
10
10
  npm install @taylorwong/ichartjs@^2
11
11
  ```
12
12
 
13
- For environments without npm registry access, install from GitHub as a fallback: `npm install github:wanghetommy/ichartjs#v2.0.11`.
13
+ For environments without npm registry access, install from GitHub as a fallback: `npm install github:wanghetommy/ichartjs#v2.0.14`.
14
14
 
15
15
  Use the package through a bundler or another environment that resolves npm ESM imports:
16
16
 
@@ -40,12 +40,14 @@ Agent usage and development guide for project planning, delivery tracking, and p
40
40
  - Gantt `start` and `end` must be valid dates, and `end` cannot precede `start`.
41
41
  - `progress` uses the `0–100` percentage convention.
42
42
  - `dependencies` use stable task IDs, either as strings or `{ id, type, lag, lead }` objects, and must form an acyclic graph.
43
+ - Dependency objects support `finish-to-start`, `start-to-start`, `finish-to-finish`, and `start-to-finish`. Rendering uses the matching task endpoints; a clear forward finish-to-start relationship uses a compact three-segment route, while overlapping or reverse relationships use a safe outer route.
43
44
  - Issue aging requires an explicit ISO `today` reference; missing or invalid dates produce warnings instead of guessed buckets.
44
45
  - Calendar-aware scheduling may also use dependency objects with explicit `type`, `lag`, and `lead`.
45
46
  - `baselineStart`/`baselineEnd` and `actualStart`/`actualEnd` should be treated as explicit source inputs, not inferred values.
46
47
  - Burndown `scopeChange` represents scope movement, not completed work.
47
48
  - A forecast is an estimate derived from current samples, not a commitment or fact.
48
49
  - Capacity warnings, risk quadrants, and aging buckets should stay explainable from source fields.
50
+ - Gantt, Timeline, and Milestone reserve their left label column from Unicode-aware text widths. Labels wider than the bounded column are truncated by rendered width rather than character count.
49
51
 
50
52
  ## Editing
51
53
 
@@ -85,6 +87,7 @@ Typical operations:
85
87
 
86
88
  - All four project chart types initialize in the Gallery.
87
89
  - Gantt dependencies, critical-path results, and variance overlays are explainable.
90
+ - Dependency paths connect the endpoints declared by their dependency type; an unobstructed forward finish-to-start path has at most three segments.
88
91
  - Burndown scope changes and forecasts have dedicated tests.
89
92
  - Capacity, risk, and aging analytics preserve stable record IDs.
90
93
  - Editing commands support preview, commit, undo, and redo.
@@ -91,6 +91,8 @@ All export/download methods return a stable `{ valid:false, code, message?, sugg
91
91
 
92
92
  ## Common APIs
93
93
 
94
+ State-changing calls use one validation boundary. `update()` and `setData()` return the chart when committed; invalid input throws `ChartValidationError` with stable `code`, `details`, `path`, `expected`, `received`, and `suggestion` fields. The previous Spec, Scene, selection, revision, and history remain unchanged after a rejected mutation. `applyPatch()` is an advanced JSON-pointer API and is validated before commit.
95
+
94
96
  ```text
95
97
  inspectData(data)
96
98
  normalizeData(data)
@@ -105,6 +107,8 @@ validatePreferences(patch, options)
105
107
  chart.describe()
106
108
  chart.explain()
107
109
  chart.getState()
110
+ chart.getState().health
111
+ chart.explain().health
108
112
  chart.getPreferences()
109
113
  chart.setPreferences(patch, options)
110
114
  chart.resetPreferences(options)
@@ -121,7 +121,7 @@ npx skills add wanghetommy/ichartjs --skill ichartjs --agent codex --global --ye
121
121
  For reproducible installation, pin the released Skill directory:
122
122
 
123
123
  ```bash
124
- npx skills add https://github.com/wanghetommy/ichartjs/tree/v2.0.11/skills/ichartjs \
124
+ npx skills add https://github.com/wanghetommy/ichartjs/tree/v2.0.14/skills/ichartjs \
125
125
  --agent codex --global --yes
126
126
  ```
127
127
 
@@ -35,13 +35,15 @@
35
35
  | 坐标轴标题和格式 | `xAxis.title/format`、`yAxis.title/format` | Line、Area、Bar、Column、Scatter |
36
36
  | 易读数值域 | `yAxis.nice`、`yAxis.ticks`、`yAxis.domain` | Line、Area、Bar、Column、Scatter |
37
37
  | 数据标签 | `labels.enabled/format` | 能力清单声明支持 labels 的图表 |
38
- | 图例 | `legend.visible/position` | 多系列笛卡尔图、Pie、Radar |
38
+ | 图例 | `legend.visible` | 多系列笛卡尔图、Pie、Radar |
39
39
  | Gauge 坐标域 | `domain: [min, max]` | Gauge |
40
40
  | Heatmap 颜色域 | `colorScale.domain` | Heatmap |
41
41
  | Radar 指标域 | `indicators[].min/max` | Radar |
42
42
 
43
43
  不要把 `title`、`format`、`labels` 或 `legend` 放在 `encoding` 中;`validateSpec()` 会报告结构化警告。数值纵轴默认使用易读域(`nice: true`、`ticks: "auto"`);需要固定范围时使用 `yAxis.domain: [min, max]`,需要保留原始边界时使用 `yAxis.nice: false`。分类/时间横轴的 `min/max` 和 `domain` 不支持。
44
44
 
45
+ 布局保持确定性且不依赖 Renderer。图例使用 Unicode-aware 文本宽度估算来计算间距,并在单行空间不足时自动换行;单个标签仍无法放入可用宽度时会省略并报告 `LEGEND_OVERFLOW`。Y 轴标题都在刻度列外侧居中显示;Bar 的分类 Y 轴标题也会在左侧垂直居中,并在确定绘图区之前预留空间。如果图表高度确实不足以容纳标题,渲染器才会截断,并报告 `TITLE_TRUNCATED`。坐标轴和项目标签空间会在确定绘图区之前完成预留,因此 Canvas、SVG、Headless 和导出共享相同几何。
46
+
45
47
  ## Encoding 契约
46
48
 
47
49
  不同图表只接受对应的数据通道:笛卡尔图表使用 `encoding.x`/`encoding.y`;Pie、Funnel 使用 `encoding.category`/`encoding.value`;Gauge 只使用 `encoding.value`;Heatmap 使用 `encoding.x`/`encoding.y`/`encoding.color`;Radar 使用 `indicators[].field`。字段不存在或通道不支持会成为校验错误,不应静默改名。Gauge 必须提供 `domain: [min, max]`;超出范围时弧形会限制在范围内,并产生 `VALUE_CLAMPED`。Pie 遇到负值会报告 `NEGATIVE_VALUE_DROPPED`,没有正数占比时会报告 `ZERO_TOTAL`。全部图表的最小可执行 Spec 见 `@taylorwong/ichartjs/recipes/minimal-specs`;ESM 中用 `with { type: 'json' }` 导入,并从 `catalog.examples[type]` 取模板。
@@ -22,7 +22,7 @@ npm Registry 中无作用域的 `ichartjs` 是安全占位包,并非本项目
22
22
  npx skills add wanghetommy/ichartjs --skill ichartjs
23
23
  ```
24
24
 
25
- Codex 全局无交互安装可追加 `--agent codex --global --yes`。需要固定发布版本时,安装 `https://github.com/wanghetommy/ichartjs/tree/v2.0.11/skills/ichartjs`。WorkBuddy 可通过自身 Skill 界面导入该带 Tag 的目录;只有当前 CLI 明确声明对应适配器时才使用宿主专用 `--agent` 参数。
25
+ Codex 全局无交互安装可追加 `--agent codex --global --yes`。需要固定发布版本时,安装 `https://github.com/wanghetommy/ichartjs/tree/v2.0.14/skills/ichartjs`。WorkBuddy 可通过自身 Skill 界面导入该带 Tag 的目录;只有当前 CLI 明确声明对应适配器时才使用宿主专用 `--agent` 参数。
26
26
 
27
27
  使用 `npx skills add wanghetommy/ichartjs --list` 验证发现结果,其中应包含 `ichartjs`。
28
28
 
@@ -11,6 +11,21 @@
11
11
 
12
12
  架构图和思维导图都属于结构化图,但不能混用:架构图表达明确的领域或系统关系,思维导图表达想法层级。
13
13
 
14
+ Architecture 的 `layers` 是从上到下排列的水平分层。同层自动布局节点优先保持同一 Y 坐标并从左到右排列;只有可用宽度不足时才增加下一行。显式 `node.position` 始终优先,包括编辑后的坐标;自动布局不会回写 Spec。
15
+
16
+ ```js
17
+ {
18
+ type: 'architecture',
19
+ layers: [{ id: 'access', label: '接入层' }, { id: 'service', label: '服务层' }],
20
+ nodes: [
21
+ { id: 'web', label: 'Web 前端', layerId: 'access' },
22
+ { id: 'gateway', label: 'API 网关', layerId: 'access' },
23
+ { id: 'order', label: '订单服务', layerId: 'service' }
24
+ ],
25
+ edges: [{ from: 'gateway', to: 'order' }]
26
+ }
27
+ ```
28
+
14
29
  思维导图建议使用简洁的父子数据:
15
30
 
16
31
  ```js
@@ -45,6 +60,7 @@ Mindmap 默认使用曲线父子连线。`diagram.curveTension` 支持 `0.2` 到
45
60
  - Group 只支持平级 Group,不支持嵌套。
46
61
  - Group bounds 由成员几何和 `group.padding` 推导;`resizeGroup` 会缩放成员位置和尺寸,不持久化第二个 Group 矩形。
47
62
  - Canvas 提供基础无障碍文本,SVG 提供更丰富的 Diagram 语义。
63
+ - Architecture 混用手工坐标与自动坐标时可能发生重叠;运行时会保留手工坐标,不会静默搬动节点。
48
64
 
49
65
  ## Agent 流程
50
66
 
@@ -63,4 +79,4 @@ Mindmap 默认使用曲线父子连线。`diagram.curveTension` 支持 `0.2` 到
63
79
  - 专用 Demo:`playground/diagram-editor.html`
64
80
  - 全量 Gallery:`playground/project-gallery.html`
65
81
 
66
- 节点移动后必须验证边、箭头和标签跟随;同时检查 Canvas 与 SVG 的边命中、手柄拖动、waypoint 持久化、键盘和导出一致性。
82
+ 节点移动后必须验证边、箭头和标签跟随;Architecture 无显式坐标的同层节点应横向优先排列;同时检查 Canvas 与 SVG 的边命中、手柄拖动、waypoint 持久化、键盘和导出一致性。
@@ -25,5 +25,7 @@ const result = chart.applyEdit(command, { preview, confirmed: true, source: 'age
25
25
  - 外部持久化、权限和认证由 Host 应用负责。
26
26
  - 指针导航和编辑默认关闭。`editing.enabled` 授权编辑事务;`interaction.drag`、`interaction.edgeDrag`、`interaction.portConnect` 分别控制直接操作 UI。
27
27
  - Diagram 边通过 JSON-safe 的 `waypoints` 持久化;路径更新使用 `updateEdge`,删除使用 `removeEdge`,并要求结构编辑权限。
28
+ - Mindmap 边使用独立的 `mindmap-edge` 契约,但与 Flow、Architecture 共享相同的边编辑语义。
29
+ - `update()`、`setData()`、`setTheme()` 和偏好设置输入失败时抛出结构化 `ChartValidationError`,失败不会推进 revision 或破坏历史。
28
30
 
29
31
  Schema、命令、Preview/Commit、事务和历史的实现分别位于 `src/schema.mjs`、`src/command.mjs`、`src/edit.mjs`、`src/edit-controller.mjs` 和 `src/history.mjs`。
@@ -6,7 +6,7 @@ iChart.js 应作为普通 JavaScript UI 组件运行在浏览器应用中。数
6
6
  npm install @taylorwong/ichartjs@^2
7
7
  ```
8
8
 
9
- 无法访问 npm Registry 的环境请用 GitHub 源作为后备:`npm install github:wanghetommy/ichartjs#v2.0.11`。
9
+ 无法访问 npm Registry 的环境请用 GitHub 源作为后备:`npm install github:wanghetommy/ichartjs#v2.0.14`。
10
10
 
11
11
  ```js
12
12
  import { createChart } from '@taylorwong/ichartjs';
@@ -15,9 +15,11 @@
15
15
 
16
16
  - 日期必须有效,Gantt 的 `end` 不得早于 `start`。
17
17
  - `progress` 使用 `0–100` 百分比。
18
- - `dependencies` 使用稳定任务 ID,依赖图不能有环。
18
+ - `dependencies` 使用稳定任务 ID,支持字符串或 `{ id, type, lag, lead }` 对象,依赖图不能有环。
19
+ - 依赖类型支持 `finish-to-start`、`start-to-start`、`finish-to-finish` 和 `start-to-finish`;连线使用对应任务端点。具有净空的正向 FS 关系使用三段紧凑路径,重叠或反向关系使用外侧绕行。
19
20
  - `scopeChange` 表示范围变化,不等于已完成工作量。
20
21
  - Forecast 是估计结果,不能描述为承诺或事实。
22
+ - Gantt、Timeline 和 Milestone 根据 Unicode-aware 文本宽度预留左侧标签列;超过列宽的标签按像素省略,不按字符数截断。
21
23
 
22
24
  ## 编辑流程
23
25
 
@@ -37,4 +39,4 @@ Schema → Command → Validate → Preview → Confirm → Commit → ChangeSet
37
39
  - 测试:`tests/core.test.mjs`
38
40
  - 验收:`playground/project-gallery.html`
39
41
 
40
- 需要覆盖日期错误、循环依赖、Scope Change、Forecast 和编辑历史。
42
+ 需要覆盖日期错误、循环依赖、四种依赖类型端点、FS 三段路径、Scope Change、Forecast、中文标签边界和编辑历史。