@iodes/releasekit 0.1.6 → 0.2.0

package/kit/references/composition-recipes.md

@@ -6,8 +6,8 @@ The rules below are conditional on the selected subject. Choose the [media sourc
 
 | Archetype | Use when | Starting composition | Common failure |
 | --- | --- | --- | --- |
-| `icon-tile` | A capability or status is recognizable through one symbol | Flat tile about 20–24% of canvas width; neutral monochrome filled glyph about 50–65% of tile width | A sculpted 3D object, colored decorative badge, or oversized glyph |
-| `symbol-pair` | Two capabilities are connected | Two equally weighted neutral symbols, a short subtle divider, broad empty space | Coloring one symbol merely for emphasis, unequal weights, or an unsupported direction |
+| `icon-tile` | A capability or status is recognizable through one symbol | Flat tile about 20–24% of canvas width; compact filled glyph about 50–65% of tile width, normally neutral with accent available for a supported action or state | A sculpted 3D object, colored decorative badge, or oversized glyph |
+| `symbol-pair` | Two capabilities are connected | Compact neutral glyphs, each longest dimension around 8–11% of canvas width; generous spacing and a short subtle divider | Coloring one symbol merely for emphasis, unequal weights, or an unsupported direction |
 | `ui-detail` | A specific interaction or setting changed | One enlarged fragment occupying about 55–85% of width | A complete invented dashboard with the useful control too small |
 | `device-view` | The device or cross-device context matters | One unobtrusive front-facing display, around 28–48% of width | Decorative device mockups unrelated to the workflow |
 | `object-detail` | A real physical part explains the feature | Supplied photograph or capture, with a useful crop | Inventing a physical product or generating a 3D substitute |
@@ -46,15 +46,15 @@ Message: a saved item can be added to a queue with one swipe.
 
 Choose `ui-detail`. Three broad horizontal list rows extend slightly past the right crop. Define the resting list left boundary as `L` and the exposed action width as `D`. The top and bottom row backgrounds and the middle row's action backplate all start at `L`. For this rightward swipe, only the middle foreground row starts at `L + D`; its thumbnail and label bars move with it and retain their original padding. The action occupies the space revealed inside the original row bounds. Its left edge must not protrude outside the resting list. Do not shift the entire list or compress the active row to make room.
 
-Represent incidental text as two or three neutral bars with consistent padding. Assign these bars to `secondary`, base rows to `surface`, and abstract thumbnails to `raised`. Keep repeated roles consistent; vary tone only for a hierarchy supported by the scene. Keep the action icon recognizable and the entire interaction inside the safe margin. This is a horizontal reveal gesture, not a vertical reorder drag: the rows keep their order and vertical positions. Keep one interaction. The exposed action may use accent if color helps distinguish it; neutral value contrast is also valid. Do not add a floating hand, arrow trail, extra feature, or surrounding app navigation.
+Represent incidental text as two or three neutral bars with consistent padding. Assign roles according to the scene's hierarchy: incidental bars and thumbnails can share `secondary`, with foreground rows in `raised` over the canvas. Use `surface` for a base or recessed panel when present. A feature-relevant title or value can use `primary` if its hierarchy matters. Keep equivalent roles consistent across the release and both themes. Keep the action icon recognizable and the entire interaction inside the safe margin. This is a horizontal reveal gesture, not a vertical reorder drag: the rows keep their order and vertical positions. Keep one interaction. Prefer the project accent on the exposed action so readers can locate the available operation quickly, even when the swipe geometry also reads in grayscale. Keep the supporting rows neutral; honor an explicit monochrome brief or authentic product color scheme. Do not add a floating hand, arrow trail, extra feature, or surrounding app navigation.
 
-Before pairing, check that the resting rows and action backplate share a left boundary, the foreground displacement equals the revealed action width, and its contents moved as one unit. For the theme pair, lock row dimensions, offset, action width, bars, crop, and selected state. Change only canvas and surface roles, neutral label values, and local shadows. A second view that selects another row is a failed pair. Two matching images can still share the same interaction error, so correspondence alone is insufficient.
+Before pairing, check that the resting rows and action backplate share a left boundary, the foreground displacement equals the revealed action width, and its contents moved as one unit. For the theme pair, lock row dimensions, offset, action width, bars, crop, and selected state. Change only neutral presentation values and necessary surface separation within the recipe. A second view that selects another row is a failed pair. Two matching images can still share the same interaction error, so correspondence alone is insufficient.
 
 ## Worked brief: a saved-location preference
 
 Message: a setting can be saved for a selected location.
 
-Choose `symbol-pair` if the association itself is sufficient: a simple adjustment glyph and a location pin, balanced around a narrow neutral divider. Choose `ui-detail` if users need to discover the new menu action. Do not add a device just to fill the empty space. A location pin is a metaphor; it must not imply geofencing or automatic behavior absent from the evidence.
+Choose `symbol-pair` if the association itself is sufficient: a compact adjustment glyph and a location pin, balanced around a short neutral divider. Compare filled ink weight rather than forcing equal widths; a solid pin may need a narrower silhouette than a sparse adjustment glyph. Leave generous space between symbols. Establish this geometry once in the shared scene and retain it in both themes. Choose `ui-detail` if users need to discover the new menu action. Do not add a device just to fill the empty space. A location pin is a metaphor; it must not imply geofencing or automatic behavior absent from the evidence.
 
 ## Worked brief: activity information
 

package/kit/references/format.md

@@ -1,6 +1,6 @@
 # Content contract
 
-Project configuration is `releasekit/config.yaml`. Releases live under `releasekit/releases/<version>/`. Version IDs are filesystem-safe strings, not necessarily semantic versions. A release stores its configured locales and visual policy so future project-default changes do not rewrite past releases. New projects default to English originals (`sourceLocale: en-US`, `locales: [en-US]`). On first use, the agent asks about optional translations only when language choices remain unresolved, then saves the selected source and translations in `releasekit/config.yaml` before preparation. Each new release copies the current project `sourceLocale`, `locales`, and visual policy. Later drafts use those configured languages without asking again, including a single-language choice. Previous releases' language selections do not override config. Explicit release-only language changes are saved in the affected `release.yaml`, preserving project defaults and other releases.
+Project configuration is `releasekit/config.yaml`. Channel-free releases live under `releasekit/releases/<version>/`; channel releases use `releasekit/releases/<channel>/<version>/`. See [channels](channels.md) for optional config, qualified identities, and cross-channel display links. Version IDs are filesystem-safe strings, not necessarily semantic versions. A release stores its configured locales and visual policy so future project-default changes do not rewrite past releases. New projects default to English originals (`sourceLocale: en-US`, `locales: [en-US]`). On first use, the agent asks about optional translations only when language choices remain unresolved, then saves the selected source and translations in `releasekit/config.yaml` before preparation. Each new release copies the current project `sourceLocale`, `locales`, and visual policy. Later drafts use those configured languages without asking again, including a single-language choice. Previous releases' language selections do not override config. Explicit release-only language changes are saved in the affected `release.yaml`, preserving project defaults and other releases.
 
 Optional `history.start` in the project config records first-use setup: `ref` is the original commit/tag label, `sha` is its immutable commit, `past` is `summary`, `history`, or `skip`, and `version` is the baseline release ID for summary/history or null for skip. `releasekit start` saves this once before any release exists. It creates no content. Existing configs without this field retain the explicit-range workflow. See [first-use setup](adoption.md).
 
@@ -14,11 +14,11 @@ Within one release:
 | `prompts/<id>.<theme>.md` | Generation requests for pending generated variants; supplied images have no generation request |
 | `assets/` | Selected raster files with content-derived names |
 
-`visuals.dark` and `visuals.light` assign six neutral roles: `canvas` for the background, `surface` for base panels, `raised` for tiles and abstract thumbnails, `primary` for main glyphs, `secondary` for incidental bars and detail, and `divider` for thin boundaries. See the [role table](visual-language.md#assign-neutral-colors-by-role). Values are fixed per role within the captured theme policy; do not derive a separate palette for each note. Updating the toolkit does not overwrite existing project colors or release snapshots. To adopt new defaults in an existing project, edit `releasekit/config.yaml`; use `image plan --sync-config` to apply that project policy to a draft.
+`visuals.dark` and `visuals.light` assign six neutral roles: `canvas` for the background, `surface` for base or recessed panels, `raised` for foreground panels and controls, `primary` for main glyphs and focal marks, `secondary` for supporting glyphs, bars, and abstract content, and `divider` for thin boundaries. The scene maps elements by hierarchy rather than fixing one role to every instance of an object type. See the [role table](visual-language.md#assign-neutral-colors-by-role). Values are fixed per role within the captured theme policy; do not derive a separate palette for each note. Updating the toolkit does not overwrite existing project colors or release snapshots. To adopt new defaults in an existing project, edit `releasekit/config.yaml`; use `image plan --sync-config` to apply that project policy to a draft.
 
 `visuals.accent` makes a project color available for generated images; it does not require that color in every image. In the shared scene's `composition`, record no accent or the exact colored element and its supported state, action, or information meaning. Keep that assignment in `preserve`; neutral scenes remain neutral in both themes.
 
-Each `(version, note.id, variant)` has one selected image. Importing replaces the selected slot and then removes unused managed images belonging to this note, including obsolete shared or themed imports. Files referenced by any visual variant or scene in the project are retained, as are other notes' files and source originals outside the note's managed assets. Reimporting identical content reuses its file. Keep existing variant entries until the replacement import succeeds.
+Each `(channel?, version, note.id, variant)` has one selected image. Importing replaces the selected slot and then removes unused managed images belonging to this note, including obsolete shared or themed imports. Files referenced by any visual variant or scene in the project are retained, as are other notes' files and source originals outside the note's managed assets. Reimporting identical content reuses its file. Keep existing variant entries until the replacement import succeeds.
 
 Importing `--theme shared` replaces the note's dark/light entries with one shared entry. Importing `--theme dark` or `light` replaces a shared entry and keeps compatible themed entries. Optional `--source generated|provided` updates `scene.source` in the same save as the imported selection; omission preserves the current source. Shared imports require supplied media, and supplied-only subjects still reject generated media. The CLI validates the file before saving, so decoding or metadata-save failure preserves the previous source and selections. A missing configured counterpart stays pending after the first themed import and blocks finalization. See [image transitions](theme-pairing.md#switch-between-shared-and-themed-images).
 
@@ -28,11 +28,11 @@ Adding a note creates the release's saved locale files and clears `emptyReason`.
 
 Preparation writes only `release.yaml`: `source` records the immutable Git boundaries, and each note later records its relevant commits or paths. No full patch or separate changed-file index is stored. Draft validation checks note references against the pinned Git range or the baseline snapshot for a summary; finalization fingerprints the metadata, note text, and visual briefs. Ready content can be validated and exported without Git history.
 
-Optional `initialContent` in a baseline release snapshots the selected `summary` or `history` mode. Either mode requires `source.fromRef: null`, `source.fromSha: null`, and `previous: null`. A summary describes the product at `source.toSha`; its evidence may reference only that SHA or tracked paths in that snapshot. History mode analyzes the full history through that SHA with normal range evidence. This distinction is preserved in the content fingerprint but excluded from consumer JSON. An absent field keeps the existing range semantics, including full history when `fromSha` is null; loading old files adds no defaults or changes to their fingerprints.
+Optional `initialContent` in a baseline release snapshots the selected `summary` or `history` mode. Either mode requires `source.fromRef: null` and `source.fromSha: null` (a root Git range). Display predecessors are independent and may change during a whole-release move. A summary describes the product at `source.toSha`; its evidence may reference only that SHA or tracked paths in that snapshot. History mode analyzes the full history through that SHA with normal range evidence. This distinction is preserved in the content fingerprint but excluded from consumer JSON. An absent field keeps the existing range semantics, including full history when `fromSha` is null; loading old files adds no defaults or changes to their fingerprints.
 
 The next release begins after the baseline SHA and links to its version with `previous`. A skipped past creates no baseline release: the first regular draft uses the saved start, and later drafts use explicit boundaries or previous links. Baseline entries count toward the export limit just like other releases.
 
-Notes are ordered by their entries in `release.yaml`. Note IDs are unique within a version and shared across locales. Their consumer identity is the pair `(version, note.id)`; never deduplicate different releases by note ID or title alone.
+Notes are ordered by their entries in `release.yaml`. Note IDs are unique within a version and shared across locales. Their consumer identity is `(channel?, version, note.id)`; never deduplicate different releases by note ID or title alone.
 
 A grouped minor-change note uses the same contract: one note ID, category `fix` or `improvement`, a localized summary title, and an unordered Markdown list in the body. Its metadata carries the evidence paths or commits covering all bullets. Bullets have no separate note records or images; the group uses the normal image and translation policy and exports as one note with its list in `bodyMarkdown`. See [grouping guidance](writing.md#group-minor-changes) for selection and titles.
 
@@ -46,6 +46,16 @@ The `releasekit-finalize` skill reviews the release and runs `releasekit finaliz
 
 The generated JSON schemas shipped with the package are the structural source of truth. `releasekit export --out <directory>` produces one `release-notes.<locale>.json` per locale saved in the current release, with shared relative image assets in `assets/`. `--locale <locale>` selects one language and keeps the same filename pattern. Each JSON file uses the existing bundle schema and includes only display fields, configured image variants, its locale, and explicit version groups. Source patches, prompts, internal paths, and Git evidence are not included. Consumers should safely render `bodyMarkdown` and use image `variants[theme]` or `variants[fallbackTheme]` without recoloring the raster.
 
-Only `--out` is required. Without `--current`, export selects the unique release that no other saved release names as `previous`, regardless of version spelling, date, or directory order. No releases or cyclic links prevent automatic selection; multiple endpoints require `--current`. A draft endpoint must be finalized before export. Without `--limit`, export uses project `history.limit` (initially 3), following `previous` links. The locales saved in the current release determine the default language set, independently of later project configuration changes. Every selected release must contain each requested locale; missing or stale translations fail the whole export before creating output. The command result contains a `files` array of JSON paths, a `releases` count of version groups, and an `assets` count of image files copied once across locales.
+For unchanneled exports, only `--out` is required. Without `--current`, export selects the unique release that no other saved release names as `previous`, regardless of version spelling, date, or directory order. No releases or cyclic links prevent automatic selection; multiple endpoints require `--current`. A draft endpoint must be finalized before export. Without `--limit`, export follows the entire `previous` chain. `--limit N` accepts any positive safe integer; there is no fixed 100-release cap. Remove obsolete `history.limit` settings and pass an export option instead. The locales saved in the current release determine the default language set, independently of later project configuration changes. Every selected release must contain each requested locale; missing or stale translations fail the whole export before creating output. The command result contains a `files` array of JSON paths, a `releases` count of version groups, and an `assets` count of image files copied once across locales.
 
 An export destination must not already exist. This avoids overwriting content or mixing assets from separate builds. Validation completes before the destination is created.
+
+## Optional channel fields and timestamps
+
+`channels` is absent before the first choice, `false` for explicit non-use, or a nonempty map of channel names to `{ include, history? }`. Each include list is nonempty, unique, and references configured names directly. Channel names use lowercase letters, digits, and hyphens, beginning with a letter; filesystem-reserved names are rejected. `history` is optional and contains only `start`; `history.limit` is no longer supported.
+
+Release `channel` is optional. A channel release has `previous: { channel, version }` or null; an unchanneled release retains a version string or null. The global channel chain must contain every channel release exactly once. Unchanneled releases are not members of that chain. New channel drafts link to its latest member; their Git comparison start instead comes from explicit `--from`, the most recent release of the same channel, or that channel's saved start. Existing schemaVersion values and absent fields are preserved.
+
+Channel export adds `viewChannel` and `currentChannel` at the top level and `channel` on every release entry. `currentVersion`/`currentChannel` identify the first displayed entry. Exported channel `previous` points to the next entry included in the output, ending with null; the source links remain unchanged. Images use `assets/<channel>/<version>/...`. Channel-free output retains its existing fields and paths.
+
+`releasedAt` accepts a valid `YYYY-MM-DD` date or an ISO timestamp with seconds, optional one-to-three fractional digits, and `Z` or an explicit UTC offset. Timezone-less times are rejected. Preparation defaults to `new Date().toISOString()`; explicit input strings and existing date-only values are preserved. The display chain, not timestamps or semantic version comparison, determines order.

package/kit/references/theme-pairing.md

@@ -10,7 +10,7 @@ This generation policy does not require inventing a second appearance for suppli
 
 Policy is captured in each release when it is prepared. Editing the project default affects new releases. To apply the current project policy to an existing draft, run `releasekit image plan <version> --sync-config`. Previously selected files are retained; themes disabled by the new policy are not exported. Ready releases must be reopened before their policy changes.
 
-For a requested palette correction, change the relevant saved theme roles at the requested project or release scope before generating replacements. A project change belongs in `releasekit/config.yaml`; sync that policy into the target draft with `releasekit image plan <version> --sync-config`. A release-only change belongs in that draft's captured visual policy. Do not work around a saved dark glyph value by adding a one-off lighter color to a prompt. Regenerate and review the affected requested variants; preserve unchanged accepted counterparts. Palette changes are authoring policy changes, not a global filter over supplied images.
+For a requested palette correction, change the relevant saved theme roles at the requested project or release scope before generating replacements. A project change belongs in `releasekit/config.yaml`; sync that policy into the target draft with `releasekit image plan <version> --sync-config`. A release-only change belongs in that draft's captured visual policy. Do not work around a saved dark glyph value by adding a one-off lighter color to a prompt. Regenerate and review the affected requested variants; preserve unchanged accepted counterparts. A light-only palette correction does not request dark regeneration. If the shared geometry needs correction, update the scene and review both affected variants, keeping each theme's palette. Palette changes are authoring policy changes, not a global filter over supplied images.
 
 ## Coverage and repeat runs
 
@@ -24,13 +24,13 @@ An existing image reported as stale or invalid is unresolved, even though its fi
 
 ## One scene, two presentation treatments
 
-Both outputs share the same scene brief. Lock subject identity, geometry, object count, positions, scale, crop, camera, UI topology, action state, chart values, and any allowed literal labels. Change presentation surfaces, neutral values, lighting, shadows, and necessary edge separation. Preserve meaningful status colors and natural photographic or material colors. Lock the absence of accent for a neutral scene; when accent is justified, keep it on the same meaningful elements in both variants. A theme change does not introduce an accent.
+Both outputs share the same scene brief. Lock subject identity, geometry, object count, positions, scale, crop, camera, UI topology, action state, chart values, and any allowed literal labels. Change neutral presentation values and necessary surface separation within the selected recipe. Match geometry, not apparent brightness or contrast: use each theme's independent treatment. Preserve meaningful status colors and natural photographic or material colors. Lock the absence of accent for a neutral scene; when accent is justified, keep it on the same meaningful elements in both variants. A theme change does not introduce an accent.
 
 | Role | Dark treatment | Light treatment |
 | --- | --- | --- |
 | Canvas | Quiet charcoal | Quiet near-white |
-| Interface surface | Separate adjacent dark values | Separate white and pale-gray values |
-| Primary neutral symbol | Legible mid-light neutral | Medium gray from `primary`, without default charcoal fills |
+| Interface surface | Distinguish base and foreground charcoal layers | Separate white and pale-gray values |
+| Primary neutral symbol | Compact mid-light neutral; no oversized bright glyph | Medium gray from `primary`, without default charcoal fills |
 | Secondary detail | Subdued, still distinguishable | Lighter `secondary` for incidental bars and supporting detail |
 | Surface separation | Preserve only feature-relevant layers | Use surface roles and thin dividers; do not invent shadows |
 | Optional interaction or status color | Preserve assignment and semantic hue, or keep absent | Preserve assignment and semantic hue, or keep absent |
@@ -45,13 +45,13 @@ Do not invert pixels or shift brightness globally. A black lens remains a black
 3. Generate one requested variant using its prompt. Select and inspect the result.
 4. Import it. Re-run the image plan; a valid approved counterpart is now offered as a composition reference for the other theme.
 5. When the available tool supports image references or edits, use the counterpart for a constrained theme edit. Otherwise repeat the exact scene contract and inspect for layout drift. Never claim pixel-identical geometry from independent stochastic generations.
-6. Compare the pair and the other accepted images in the same theme. Check equivalent glyphs, label bars, and surfaces against the same configured color roles, without making light images as dark or contrast-heavy as dark-theme subjects. Both files should have the same pixel dimensions. Verify pose, crop, UI state, values, and semantic colors by sight, then import the selected counterpart.
+6. Review dark images together and light images together at equal display widths, then compare the pair. Check glyph ink size, supporting detail, and charcoal layer separation in dark; check medium-gray neutral symbols and soft supporting values in light. Check equivalent elements against their configured roles without forcing equal apparent contrast between themes. Both files should have the same pixel dimensions. Verify pose, crop, UI state, values, and semantic colors by sight, then import the selected counterpart.
 
 Use one file per theme, not a split canvas or a two-panel comparison image. Keep the current selection until a reviewed replacement is imported into the same slot. Do not restart the entire release when one small defect can be corrected locally.
 
 ## Replace or regenerate an image
 
-Treat replacement and regeneration as an edit to the existing release, note ID, and affected theme. Reopen a ready release as a draft before editing it. Reuse its scene brief and current assets as needed for the requested correction. A request to regenerate an image still needs work even if the unchanged asset is reported as current by the plan; report the requested replacement as pending until it has been generated, reviewed, and imported.
+Treat replacement and regeneration as an edit to the existing release, note ID, and affected theme. A requested accent-use correction updates the shared scene's color assignment; regenerate the affected variants while preserving unrelated geometry and theme palettes. Reopen a ready release as a draft before editing it. Reuse its scene brief and current assets as needed for the requested correction. A request to regenerate an image still needs work even if the unchanged asset is reported as current by the plan; report the requested replacement as pending until it has been generated, reviewed, and imported.
 
 Keep the existing variant metadata while preparing the candidate, then run `releasekit image import <version> <note> --theme <theme> --file <selected-file>` for the same slot. Import validates the candidate and saves the new selection before removing unused managed images for this note, including older imports and obsolete shared/themed files. Reimporting identical bytes reuses the same file. Other selected variants, notes, releases, declared image references, and original source files outside the note's managed assets are preserved. If decoding or saving fails, the previous source and selection remain intact; report the replacement as pending.
 

package/kit/references/visual-language.md

@@ -29,38 +29,38 @@ For each standalone note, derive the scene from that feature independently. Grou
 
 Separate the canvas, base surface, raised surface, primary symbol, secondary detail, and divider. These are semantic roles, not a global color filter. The project defines their dark and light values.
 
-On dark backgrounds, distinguish charcoal layers and use mid-light neutral symbols. Do not crush a dark object into the canvas or turn every small glyph pure white. On light backgrounds, use near-white space, subtle gray separation, and medium-gray symbols with lighter supporting details. Do not use charcoal glyphs or dark placeholder bars by default. A dark device or natural photo may stay dark in a light presentation.
+Judge each theme at the same display width using its own saved palette. On dark backgrounds, retain distinct charcoal layers and compact mid-light neutral symbols; keep supporting UI quieter than the focal control. Avoid oversized bright glyphs, thick label bars, and milky overlays. On light backgrounds, use near-white space, subtle gray separation, and medium-gray neutral symbols with lighter supporting details. Do not use charcoal glyphs or dark placeholder bars by default. A dark device or natural photo may stay dark in a light presentation. Equal geometry does not require equal apparent brightness or contrast. A light-only palette correction leaves the accepted dark treatment intact.
 
-For icons, use a compact flat rounded-square tile with a neutral monochrome filled glyph and clear negative space. A typical tile occupies 20–24% of the canvas width, with the glyph around 50–65% of the tile width. Keep broad margins, uniform background fills, and related corner radii. Use color only when the feature gives it a functional meaning. Do not default to a colored badge, physical object, or modeled icon.
+For generic capability icons, use a compact flat rounded-square tile with a neutral monochrome filled glyph and clear negative space. A typical tile occupies 20–24% of the canvas width, with the glyph around 50–65% of the tile width. Keep broad margins, uniform background fills, and related corner radii. Use color only when the feature gives it a functional meaning. Do not default to a colored badge, physical object, or modeled icon.
 
 Flat icons and symbol pairs have no perspective, extrusion, material texture, gradients, lighting, or shadows. Simplified interfaces may use restrained layer separation where it explains the actual control hierarchy. Preserve shading already present in supplied media. Do not add sculpted objects, decorative 3D, studio lighting, glass, glow, or bevels to generated release illustrations.
 
 ## Assign neutral colors by role
 
-Use the release's captured palette as the source of truth. The default light palette deliberately uses a narrow neutral hierarchy:
+Use the release's captured palette as the source of truth. The default palettes give the themes independent value hierarchies:
 
-| Role | Default light value | Assignment |
-| --- | --- | --- |
-| `canvas` | `#F8F8F8` | Uniform background |
-| `surface` | `#FFFFFF` | Base panels and resting rows |
-| `raised` | `#ECECEC` | Quiet tiles, inset areas, and abstract thumbnails |
-| `primary` | `#999999` | Main glyphs and feature-defining marks |
-| `secondary` | `#B8B8B8` | Incidental label bars and supporting detail |
-| `divider` | `#D9D9D9` | Thin separators and necessary boundaries |
+| Role | Default dark value | Default light value | Assignment |
+| --- | --- | --- | --- |
+| `canvas` | `#242527` | `#F8F8F8` | Uniform background |
+| `surface` | `#18191B` | `#FFFFFF` | Base or recessed panels |
+| `raised` | `#343638` | `#ECECEC` | Foreground panels, controls, and quiet tile fills |
+| `primary` | `#B9BBBE` | `#999999` | Main glyphs, focal controls, and feature-defining marks |
+| `secondary` | `#777B80` | `#B8B8B8` | Supporting glyphs, incidental bars, and abstract content |
+| `divider` | `#46494D` | `#D9D9D9` | Thin separators and necessary boundaries |
 
-Map visible schematic groups to these roles in `composition`; do not choose a fresh gray for each object or each image. Equivalent label bars share `secondary`; a second tone needs an actual hierarchy in the feature. Use the configured values, including explicit project overrides, instead of copying hex values from a worked example. Keep uniform flat fills without arbitrary warm or cool casts, opacity washes, gradients, or invented shading. Antialiased edges can contain intermediate pixels.
+Map visible schematic groups to these roles by hierarchy in `composition`; do not choose a fresh gray for each object or each image. Object type alone does not fix its role: a foreground row can use `raised`, and a subordinate thumbnail can share `secondary` with incidental bars. A feature-relevant title, value, or control may use `primary` when the scene calls for that distinction. Preserve that hierarchy across themes and equivalent scenes; do not brighten every label bar or flatten genuinely different levels into one tone. Use the configured values, including explicit project overrides, instead of copying hex values from a worked example. Keep uniform flat fills without arbitrary warm or cool casts, opacity washes, gradients, or invented shading. Antialiased edges can contain intermediate pixels.
 
 Light illustrations explain shapes and relationships without the contrast of a text document. If something is unclear at card size, improve silhouette, spacing, stroke width, scale, or crop first. Do not globally darken glyphs and placeholder bars or introduce shadows to make every element sharper. Preserve authentic dark hardware, supplied UI, content colors, and justified semantic colors; the neutral role map applies to generated schematic elements.
 
-Review same-role objects across the release's light images together, not only each dark/light pair. A successful decode and matching dimensions do not validate the palette or visual weight.
+Review same-role objects across the release's dark images together, and separately across its light images. Use equal display widths, not differently sized website cards. In dark images inspect glyph footprint and charcoal layer separation; in light images inspect soft neutral weight. A successful decode and matching dimensions do not validate the palette or visual weight.
 
 ## Color has a job
 
-Start with a fully neutral composition. Establish the focal point through placement, scale, shape, spacing, and value contrast. An image can be complete without any accent, and a release can contain many entirely neutral images. A new feature, an important capability, or the main subject does not by itself represent an active or selected state.
+Use neutral surroundings and a clear hierarchy, then choose focal color from the feature. Prefer the project accent for the primary action, a selected or enabled control, an active route, or a defined information distinction when it helps readers find what matters. Color can guide attention even when the shape or interaction also reads in grayscale; it does not have to be indispensable.
 
-Treat the project accent as an available color, not an instruction to use it. Add it only when a specific supported state, action, or information distinction needs color to explain the change: for example, an enabled switch, a selected item, a revealed action, or an active route. Even an interaction can remain neutral when its geometry and value contrast already make it clear. Keep the colored area confined to that meaningful element; leave unrelated glyphs, tiles, and supporting surfaces neutral.
+Keep the accent on the meaningful control, state, or feature-defining component; supporting glyphs, label bars, tiles, and surfaces remain neutral. Preserve an established functional accent instead of replacing it with gray merely for restraint. Use the neutral palette roles for neutral elements, not to recolor the chosen accent target. Honor explicit monochrome choices and authentic product colors.
 
-In the shared scene's `composition`, explicitly state either that no accent is used or which element uses it and what it communicates. Preserve that assignment, including the absence of accent, in both themes. Do not invent a selection, badge, status dot, or secondary marker to justify color. For `icon-tile`, ordinary capability and maintenance symbols stay neutral. For `symbol-pair`, a simple association uses the same neutral treatment for both symbols.
+In the shared scene's `composition`, name the accent target and what it communicates, or choose a neutral treatment when appropriate. Generic capability and maintenance symbols, and simple associations between symbols, normally stay neutral. A specific action or state within those archetypes may receive accent. Do not invent a selection, badge, or status just to use color. Preserve the chosen assignment across themes; revise it in the shared scene when the user requests a change in accent use.
 
 Preserve established meanings such as warnings, completed states, traffic or map semantics, chart categories, and authentic content colors between themes. These colors belong to supported information; a generic improvement or security note is not itself a success or protection status.
 
@@ -93,6 +93,6 @@ Make the brief concrete enough that another model can render the same scene. “
 
 ## Review the actual output
 
-Inspect the selected image at full resolution and at roughly 350 pixels wide. First compare the image with the release note, product evidence, and scene-specific constraints; use the chosen recipe's correctness checks. Then assess whether the changed capability reads in a moment, the focal object remains distinct, incidental detail stays subordinate, and every explicit label and crop is correct. For each accent, identify the supported meaning that would become less clear without it; if there is none, remove it. Review the release images together for repeated decorative accents. Do not give every note one colored point or enforce a fixed quota of colored images. Attractive styling and theme similarity do not establish factual or structural correctness.
+Inspect the selected image at full resolution and at roughly 350 pixels wide. First compare the image with the release note, product evidence, and scene-specific constraints; use the chosen recipe's correctness checks. Then assess whether the changed capability reads in a moment, the focal object remains distinct, incidental detail stays subordinate, and every explicit label and crop is correct. Review accent in both directions: remove decorative spread into unrelated elements, and restore the intended functional accent if it has been suppressed into gray. A useful attention cue remains valid even when the image is understandable without color. Review the release together for both overuse and habitual avoidance; do not impose a minimum, maximum, or one-colored-point-per-note quota. Attractive styling and theme similarity do not establish factual or structural correctness.
 
 For a pair, compare both outputs side by side using [theme-pairing.md](theme-pairing.md). Automated checks establish file integrity, dimensions, configured variants, and scene freshness; they do not prove visual correspondence or truthfulness. Correct a specific defect with a targeted edit instead of randomly regenerating every asset. Preserve unrelated accepted assets. Import a reviewed replacement into the same note and theme slot so unused older managed files are removed; keep the previous selection until that import succeeds.

package/kit/references/workflow.md

@@ -6,14 +6,14 @@ Use the installed `releasekit` CLI, or the repository's compiled CLI when develo
 
 The normal skill flow is `releasekit-draft` (source and selected translations), `releasekit-image` (required assets), then `releasekit-finalize` (review, validation, and local confirmation). Translation-only edits also belong to `releasekit-draft`. Skip image work for a release the user explicitly chose to keep text-only; export follows finalization only when requested.
 
-1. Read `releasekit/config.yaml` and any existing `release.yaml`. [Resolve languages](#choose-languages) from current project settings for a new draft or the saved selection for an existing draft. Ask only when a first-use choice or requested language change remains unresolved. Save the first-use selection in project config before preparation. Honor the theme policy and product context.
+1. Read `releasekit/config.yaml` and any existing `release.yaml`. [Choose channels](channels.md#first-draft-and-later-drafts) before preparing a new draft, alongside unresolved language choices. Keep the resolved channel in every subsequent command. [Resolve languages](#choose-languages) from current project settings for a new draft or the saved selection for an existing draft. Ask only when a first-use choice or requested language change remains unresolved. Save the first-use selection in project config before preparation. Honor the theme policy and product context.
 2. For a new release, [resolve the version and Git boundaries from the repository](#resolve-release-scope-from-the-repository). Reuse explicit choices and saved boundaries, inspect the relevant release line, and supply the CLI arguments yourself. Briefly state the selected scope and continue when the evidence is clear. For first-use requests with unresolved earlier-history scope, follow [the adoption guide](adoption.md) to summarize, analyze, or skip the period through the baseline.
 3. Run `releasekit prepare`. It creates only `release.yaml`, including the pinned comparison start and end SHAs. Inspect the pinned Git evidence as described below: baseline summaries read the snapshot; other drafts read history, changed paths, and relevant diffs. Do not save a full patch or a separate changed-file index.
 4. Save the selected `sourceLocale` and `locales` in this release. Use [Group minor changes](writing.md#group-minor-changes) to select standalone notes and separate minor-fix and minor-improvement groups before adding notes with `releasekit note add <version> <id>`. Give each group the corresponding `--category fix` or `--category improvement`; its bullet items do not get separate notes. Fill the source Markdown and attach evidence paths or commit SHAs to `release.yaml`, using snapshot evidence for a baseline summary. Keep every note image-enabled by default; use `--no-image` only for the user's explicit text-only choice, never to select just the important notes.
 5. As part of `releasekit-draft`, [translate the selected locales](#translate-selected-locales) and mark reviewed translations current. Finish the source and selected translations before recommending image work, unless the user explicitly limited the draft scope.
 6. Use `releasekit-image` to cover all current drafted notes, including later additions, under [the coverage policy](theme-pairing.md#coverage-and-repeat-runs). For minor groups, [reuse common originals](common-images.md) before generating new images. Choose generated or supplied media and complete each missing visual brief, reusing existing valid images on repeat runs. Run `releasekit image plan`, then handle each request by its action: generate configured variants for `generate`, or find/request an approved capture/image for `provide`. Review and import selected files, using one shared supplied asset when appropriate. Preserve unrelated accepted images and manual edits. For a replacement or regeneration, import into the same note with the intended theme; follow [image transitions](theme-pairing.md#switch-between-shared-and-themed-images) when changing shared/themed usage. Unused managed files are removed after the new selection is saved.
 7. Use `releasekit-finalize` to review factual and visual accuracy, run `releasekit validate <version>`, resolve errors and review warnings, then run `releasekit finalize <version>`. Confirm `status: ready` and a recorded content fingerprint. Review is part of finalization; a validation report alone does not complete this step.
-8. If requested, run `releasekit export --out <directory>` to export recent history to a new output directory. Omit `--current` to use the unique release with no successor in the saved `previous` links; pass an explicitly requested version or resolve multiple release endpoints with `--current <version>`. Omit `--limit` to use project `history.limit` (initially 3). Omit `--locale` to export all locales saved in the current release as separate `release-notes.<locale>.json` files sharing one `assets/` directory; pass it only when the user requests a specific output language. Every selected version must contain those locales. A finalized release is a complete local result even without an export. Finalization does not tag, commit, push, deploy, or publish anything.
+8. If requested, run `releasekit export --out <directory>` to export recent history to a new output directory. For unchanneled history, omit `--current` to use the unique release with no successor in the saved `previous` links; pass an explicitly requested version or resolve multiple release endpoints with `--current <version>`. Omit `--limit` to export all matching releases; specify it only for a requested count limit. Omit `--locale` to export all locales saved in the current release as separate `release-notes.<locale>.json` files sharing one `assets/` directory; pass it only when the user requests a specific output language. Every selected version must contain those locales. For channel output, pass the requested `--channel`; the global channel chain is filtered to ready entries in its include list. Do not choose channel-specific endpoints or sort by timestamps. A finalized release is a complete local result even without an export. Finalization does not tag, commit, push, deploy, or publish anything.
 
 For an existing draft, read and edit the existing content. `prepare` never overwrites a release. Do not recreate a folder as a shortcut for refreshing one note. Reopen a ready release by setting `status: draft` and `contentHash: null`, then make the targeted change and finalize again.
 
@@ -30,7 +30,7 @@ After additions or removals, validate the release and report outstanding copy, t
 
 ## Resolve release scope from the repository
 
-Treat versions, tags, commit SHAs, and CLI arguments as repository discovery work. Missing flags in the user's request are not by themselves a reason to open the question UI. Read the request, saved releases, applicable history-start settings, local tags, and release metadata before deciding that scope is missing.
+For channel drafts, resolve the target channel through [the channel workflow](channels.md#first-draft-and-later-drafts). Its `previous` is the latest entry across channels and is independent from the same-channel Git comparison boundary; use [channel Git boundaries](channels.md#git-boundaries). The following predecessor-based rules otherwise describe unchanneled history. Treat versions, tags, commit SHAs, and CLI arguments as repository discovery work. Missing flags in the user's request are not by themselves a reason to open the question UI. Read the request, saved releases, applicable history-start settings, local tags, and release metadata before deciding that scope is missing.
 
 - Reuse the user's explicit version and refs. For an existing draft, keep its pinned `source.fromSha` and `source.toSha` and edit in place; a moved tag does not change that draft's scope.
 - Identify the target on the requested product and release line. For a named released version, use its matching tag according to the repository's naming convention. For current unreleased work, use `HEAD`. For the latest released version, inspect the relevant release tags. Infer an omitted version only from an unambiguous tag or release metadata at the selected target; do not invent a version increment.
@@ -81,7 +81,7 @@ Questions should address an actual unresolved decision, for example:
 
 | Skill | Ask when needed | Reuse or decide without another question |
 | --- | --- | --- |
-| `releasekit-draft` | Unchosen first-use translation languages, an ambiguous requested language change, unresolved translation scope or product terminology, earlier-history treatment for first use, or materially different release scopes that repository inspection cannot resolve. | Current project languages for new drafts, saved selections for existing drafts, including a single-language choice; intentional first-use language settings; established terminology, current translations, saved boundaries, and versions or Git ranges resolved from release metadata, tags, and ancestry. |
+| `releasekit-draft` | Unchosen first-use channel use or translation languages, an unspecified new-draft channel when several are configured, an ambiguous requested language change, unresolved translation scope or product terminology, earlier-history treatment for first use, or materially different release scopes that repository inspection cannot resolve. | Current project languages for new drafts, saved selections for existing drafts, including a single-language choice; intentional first-use language settings; established terminology, current translations, saved boundaries, and versions or Git ranges resolved from release metadata, tags, and ancestry. |
 | `releasekit-image` | Ambiguous target notes or a meaningful choice among suitable approved reference images. | Captured theme policy, selected assets, and media-source requirements. Required supplied media must stay supplied; do not offer generation as an alternative. |
 | `releasekit-finalize` | Ambiguous target release or requested export choices that neither the request nor established settings resolves. | Requested fixes and local finalization, completed review when content is unchanged, valid export defaults, and already requested export. |
 

package/kit/skills/releasekit-draft/SKILL.md

@@ -1,10 +1,12 @@
 ---
 name: releasekit-draft
-description: Create or revise ReleaseKit release notes and their selected translations, including translation-only refreshes. Resolve release scope from the repository and guide first-use setup for an existing product. Use for release copy, not general code implementation.
+description: Create or revise ReleaseKit release notes and their selected translations, including translation-only refreshes and moving whole releases between channels. Resolve release scope from the repository and guide first-use setup for an existing product. Use for release copy, not general code implementation.
 ---
 
 Before asking anything, check for an unanswered question request already in this conversation. Keep that request pending across skill transitions and queue every new question until it is resolved; follow [the shared question guidance](references/workflow.md#ask-with-the-native-question-ui).
 
+For first-use channel decisions, new-draft channel selection, or whole-release channel moves, read [channels and moves](references/channels.md). Save first-use use/non-use alongside unresolved language choices before preparation; later drafts ask for a channel only when the request does not identify one and several are configured. Existing drafts retain their channel. A channel-move request is a whole-release operation through the CLI, not a copy rewrite, translation refresh, or image-regeneration task. Follow the reference's preflight and state-preserving move workflow.
+
 Read the project's ReleaseKit config and the existing release before writing. For translation-only requests, preserve the source copy, pinned scope, and accepted images; follow [Translate selected locales](references/workflow.md#translate-selected-locales) for the affected notes and languages without preparing a new release. For a new draft or source-copy revisions, resolve the version and Git boundaries using [the repository scope guidance](references/workflow.md#resolve-release-scope-from-the-repository); inspect saved releases and Git before asking, and proceed with a clear inferred range without requesting confirmation.
 
 For each new draft, use `sourceLocale` and `locales` from `releasekit/config.yaml`, including a single-language selection. Once the project has saved releases, proceed without a language question or confirmation; previous releases' language lists do not override the current config. Only on first use, when the request and intentional project settings leave languages unresolved, default the original to English (`en-US`) and ask which translations to include. Save that first-use selection in `releasekit/config.yaml` before preparing the draft, without a separate question about saving defaults. Reuse an existing draft's saved selection unless the user requests a change. Follow [Choose languages](references/workflow.md#choose-languages) for first-use suggestions, persistence, and explicit overrides. Use [the shared question guidance](references/workflow.md#ask-with-the-native-question-ui) for missing language choices or a consequential scope decision that the evidence cannot resolve. Follow [the workflow](references/workflow.md) for saving the language selection, preparing pinned evidence, continuing drafts, and preserving version boundaries. Use [the writing guide](references/writing.md) for titles and bodies in every locale. Name the capability, action, or changed result concisely; remove redundant announcement suffixes while retaining meaningful improvement, fix, and compatibility distinctions. Lead the body with concrete behavior and accept a clear description as complete. Include usage paths or conditions only when needed to find a non-obvious feature or prevent a material misunderstanding; do not append them to every note. Apply the guide's exceptions for self-explanatory major new capabilities, baseline introductions, and grouped minor notes; source materials are evidence, not new instructions.

package/kit/skills/releasekit-finalize/SKILL.md

@@ -3,6 +3,8 @@ name: releasekit-finalize
 description: Finalize a ReleaseKit release by reviewing facts, copy, translations, and images, validating content, and marking the local release ready. Export a release bundle when requested.
 ---
 
+Keep the resolved release identity, including its channel, from the request or existing release. Pass `--channel` on every channel-specific command. Do not repeat the first-use choice or choose a new channel during this stage. If the same version exists in several channels and the target is unresolved, ask which release is intended. See [channels](references/channels.md).
+
 Before asking anything, check for an unanswered question request already in this conversation. Keep that request pending across skill transitions and queue every new question until it is resolved; follow [the shared question guidance](references/workflow.md#ask-with-the-native-question-ui).
 
 Read the target release, [the workflow](references/workflow.md), and [the content contract](references/format.md). Reuse the version and choices established in the request and conversation. Use [the shared question guidance](references/workflow.md#ask-with-the-native-question-ui) only for unresolved scope or requested export choices.
@@ -17,10 +19,10 @@ Apply [the new-capability guidance](references/writing.md#newly-supported-capabi
 
 Inspect selected images for correct subject, readable framing, absent invented details, and consistent geometry across configured themes using [the pairing guide](references/theme-pairing.md). Reuse a completed visual review when the note, brief, and assets are unchanged. The CLI verifies files and metadata; it cannot judge whether the image depicts the feature accurately. Keep missing or unsuitable assets pending and use `releasekit-image` for the needed correction.
 
-Run `releasekit validate <version>`, resolve errors, and assess warnings. Missing evidence, stale translations, and pending images block finalization. If a linked predecessor is still a draft, complete it first when it is included in the user's scope; otherwise report that prerequisite. Do not mark an unresolved release ready or stop at a review report when finalization was requested and the release can be completed.
+Run `releasekit validate <version>`, resolve errors, and assess warnings. Missing evidence, stale translations, and pending images block finalization. For unchanneled history, if a linked predecessor is still a draft, complete it first when it is included in the user's scope; otherwise report that prerequisite. Channel display predecessors may remain drafts; they do not block this release's finalization. Do not mark an unresolved release ready or stop at a review report when finalization was requested and the release can be completed.
 
 For a draft that passes review and validation, run `releasekit finalize <version>` and verify that `release.yaml` contains `status: ready` and a nonempty `contentHash`. The command validates again and records the fingerprint; do not set ready status manually. For an already ready release, validate and reuse it without calling finalize again. If requested corrections require changes, reopen it with `status: draft` and `contentHash: null`, apply the corrections, and finalize again.
 
-If export was requested, run `releasekit export --out <directory>`, using [the workflow](references/workflow.md) for defaults. Add `--current`, `--limit`, or `--locale` only for requested overrides or to resolve multiple release endpoints. With no language override, export all locales saved in the current release to separate JSON files that share image assets. Preserve individual release boundaries and configured fallback themes. A successful finalization is a complete local result even when no export was requested. Finalization does not commit, tag, push, deploy, or publish.
+If export was requested, run `releasekit export --out <directory>`, using [the workflow](references/workflow.md) for defaults. For channel output, pass the requested `--channel`; it uses the global chain and skips excluded channels and drafts. `--current` is only for unchanneled output. Add `--limit` or `--locale` only for requested overrides; no limit means all matching releases. With no language override, export all locales saved in the current release to separate JSON files that share image assets. Preserve individual release boundaries and configured fallback themes. A successful finalization is a complete local result even when no export was requested. Finalization does not commit, tag, push, deploy, or publish.
 
 When finalized, report the version and link to its release file, adding bundle links only for a completed requested export. If blocked, state the remaining work and the actual saved status. Follow [the next-step workflow](references/workflow.md#continue-to-the-next-step) without introducing a separate review stage.

package/kit/skills/releasekit-image/SKILL.md

@@ -3,6 +3,8 @@ name: releasekit-image
 description: Create, revise, or import ReleaseKit release illustrations with consistent composition and project-configured dark and light variants. Use for visual release-note assets and generation prompts, not general UI implementation or arbitrary image work.
 ---
 
+Keep the resolved release identity, including its channel, from the request or existing release. Pass `--channel` on every channel-specific command. Do not repeat the first-use choice or choose a new channel during this stage. If the same version exists in several channels and the target is unresolved, ask which release is intended. See [channels](references/channels.md).
+
 Before asking anything, check for an unanswered question request already in this conversation. Keep that request pending across skill transitions and queue every new question until it is resolved; follow [the shared question guidance](references/workflow.md#ask-with-the-native-question-ui).
 
 Read the saved release's complete current note list and captured visual policy on every invocation. Default to covering every drafted note, including notes added since earlier image work; honor only the user's explicit text-only choices or explicitly limited request. Follow [coverage and repeat runs](references/theme-pairing.md#coverage-and-repeat-runs) to reuse accepted images and fill missing ones. For grouped minor fixes and improvements, follow [common images](references/common-images.md) first: reuse reviewed project originals before generating anything, and create only missing originals or themes. Choose the [media source](references/media-sources.md), then read [the visual language](references/visual-language.md) and applicable [composition recipe](references/composition-recipes.md). Use [the pairing guide](references/theme-pairing.md) for configured themes, cost-aware reuse, and importing images. Consult [the file contract](references/format.md) when editing a brief.
@@ -11,7 +13,7 @@ When a user decision is needed during image work, such as an ambiguous target fo
 
 For standalone notes, derive one visual message from the release note and its Git/product evidence. Minor groups use the common kind's generic scene, independent of their current bullet list. Choose an archetype and `source`; the scaffold leaves both unselected. Generate flat explanatory graphics when an abstraction is sufficient. `object-detail` and `editorial-scene` require supplied media, and any other type can use an actual capture when fidelity matters. Search existing approved assets or use the user's capture; if absent, ask for the specific image and keep it pending. Do not invent a physical product, content artwork, or decorative 3D scene. Examples illustrate individual features, not default layouts.
 
-Start each generated scene in neutral values and establish its focal point through composition, scale, and contrast. Map visible schematic groups to the captured palette roles in `composition`, using the [neutral role assignments](references/visual-language.md#assign-neutral-colors-by-role). Light glyphs use `primary`; incidental bars use the lighter `secondary`. Do not introduce new gray tones, tint, opacity, gradients, or shading per image. Improve geometry and spacing before darkening the palette for clarity, and preserve explicit project color overrides. In `composition`, record either no accent or the exact element and supported meaning that needs color. The configured accent is optional; a newly announced capability or a simple relationship between symbols does not justify coloring an icon. Keep generic capability and minor-group icons neutral. Preserve meaningful status, map, chart, and supplied-content colors.
+Establish a clear hierarchy with neutral supporting elements and purposeful focal color. Map visible schematic groups to the captured palette roles in `composition`, using the [neutral role assignments](references/visual-language.md#assign-neutral-colors-by-role). Assign roles by hierarchy, not object type alone, and preserve explicit project color overrides. Follow the [independent theme treatments](references/theme-pairing.md#one-scene-two-presentation-treatments): dark images retain compact mid-light neutral glyphs and necessary charcoal layers; light images use medium-gray neutral glyphs and softer supporting values. Keep flat fills consistent. Correct glyph weight and spacing in the shared scene for both themes; a light-only palette correction leaves accepted dark assets intact. In `composition`, identify the accent target and its meaning, or choose a neutral treatment when appropriate. Prefer accent for the primary action, selected/enabled state, active path, or focal information when it helps readers find the feature; it need not be indispensable in grayscale. Keep generic information and minor-group icons normally neutral. Respect explicit monochrome choices. For a requested accent revision, update the affected scene assignment instead of treating an earlier neutral choice as permanent. Preserve meaningful status, map, chart, and supplied-content colors.
 
 Complete each missing or unfinished scene brief before planning the release. Preserve the briefs of unchanged accepted images. Each note has one shared scene brief for its configured variants. Keep common minor-group scenes independent of release-specific text and evidence. For standalone scenes, encode product facts and uncertainties in `context`, the relevant state and relationships in `composition`, and the feature-specific correctness constraints in `preserve` and `avoid`. Keep reference identities and attributed style names out of prompts and assets. Inspect product references as evidence. Do not invent a concrete UI or physical design to fill missing evidence; use a supported abstraction or leave the unresolved detail in the brief.
 
@@ -21,7 +23,7 @@ For an image replacement or regeneration request, reuse the existing release and
 
 If no image generator is available, preserve the generated prompt files and report the pending assets. Continue independent editorial work. Do not silently call a paid API, install a provider, or replace requested raster illustrations with placeholders. Import user-supplied PNG, JPEG, or WebP files when they become available.
 
-Inspect selected images at full resolution and small-card size. First compare the image with the note, product evidence, and scene-specific constraints using the selected recipe's review criteria. Then check visual clarity and theme correspondence, including whether accent is absent or stays confined to its justified elements. Review the release images together for repeated decorative accents; do not assign one colored point to every note or impose a fixed color quota. The CLI checks files and metadata; it does not decide whether an image truthfully depicts the feature. Two matching variants can share the same factual or structural mistake. Correct a defect in its own scene or applicable recipe; promote it into common guidance only when the principle applies across features.
+Inspect selected images at full resolution and equal small-card widths. Review dark images together for compact glyph weight and charcoal hierarchy, then light images together for soft neutral values. First compare the image with the note, product evidence, and scene-specific constraints using the selected recipe's review criteria. Then check visual clarity and theme correspondence: an assigned functional accent must remain visible and confined to its intended elements. Review the release for both decorative overuse and suppressed functional accents; grayscale readability alone is not a reason to remove color. Do not impose a fixed color quota. The CLI checks files and metadata; it does not decide whether an image truthfully depicts the feature. Two matching variants can share the same factual or structural mistake. Correct a defect in its own scene or applicable recipe; promote it into common guidance only when the principle applies across features.
 
 If the accepted image requires an alt-text correction, update the source and affected translations using [Translate selected locales](references/workflow.md#translate-selected-locales), reviewing them before recording new source fingerprints.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@iodes/releasekit",
-  "version": "0.1.6",
+  "version": "0.2.0",
   "description": "Git-based visual release notes and portable agent skills",
   "type": "module",
   "license": "MIT",

package/schemas/bundle.schema.json

@@ -14,6 +14,14 @@
       "type": "string",
       "pattern": "^[a-z]{2,3}(?:-[A-Za-z0-9]{2,8})*$"
     },
+    "viewChannel": {
+      "type": "string",
+      "pattern": "^(?!(?:con|prn|aux|nul|com[1-9]|lpt[1-9])$)[a-z][a-z0-9-]{0,62}$"
+    },
+    "currentChannel": {
+      "type": "string",
+      "pattern": "^(?!(?:con|prn|aux|nul|com[1-9]|lpt[1-9])$)[a-z][a-z0-9-]{0,62}$"
+    },
     "releases": {
       "type": "array",
       "items": {
@@ -23,16 +31,57 @@
             "type": "string",
             "pattern": "^[a-zA-Z0-9][a-zA-Z0-9._+-]{0,95}$"
           },
-          "releasedAt": {
+          "channel": {
             "type": "string",
-            "format": "date",
-            "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$"
+            "pattern": "^(?!(?:con|prn|aux|nul|com[1-9]|lpt[1-9])$)[a-z][a-z0-9-]{0,62}$"
           },
-          "previous": {
+          "releasedAt": {
             "anyOf": [
               {
                 "type": "string",
-                "pattern": "^[a-zA-Z0-9][a-zA-Z0-9._+-]{0,95}$"
+                "format": "date",
+                "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$"
+              },
+              {
+                "type": "string",
+                "allOf": [
+                  {
+                    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"
+                  },
+                  {
+                    "pattern": "T\\d{2}:\\d{2}:\\d{2}(?:\\.\\d{1,3})?(?:Z|[+-]\\d{2}:\\d{2})$"
+                  }
+                ]
+              }
+            ]
+          },
+          "previous": {
+            "anyOf": [
+              {
+                "anyOf": [
+                  {
+                    "type": "string",
+                    "pattern": "^[a-zA-Z0-9][a-zA-Z0-9._+-]{0,95}$"
+                  },
+                  {
+                    "type": "object",
+                    "properties": {
+                      "channel": {
+                        "type": "string",
+                        "pattern": "^(?!(?:con|prn|aux|nul|com[1-9]|lpt[1-9])$)[a-z][a-z0-9-]{0,62}$"
+                      },
+                      "version": {
+                        "type": "string",
+                        "pattern": "^[a-zA-Z0-9][a-zA-Z0-9._+-]{0,95}$"
+                      }
+                    },
+                    "required": [
+                      "channel",
+                      "version"
+                    ],
+                    "additionalProperties": false
+                  }
+                ]
               },
               {
                 "type": "null"