@rockysoft/opencode-hybrid-workflow 1.0.0 → 1.1.0

package/README.md

@@ -4,6 +4,8 @@ Let your strongest models plan, design and review. Let your implementation model
 
 One plugin. One or two reviewers. Configure everything inside OpenCode.
 
+**Optional Impeccable guidance:** your design lead decides; your implementation model builds the approved design. Set it up below.
+
 **Requirements:** OpenCode 2, Node.js 22+, Git and Python 3. Windows and Linux; experimental macOS support.
 
 ## 1. Install
@@ -114,6 +116,19 @@ Type **`/hybrid`** or click **Hybrid Workflow settings** whenever you want to ch
 
 ## Optional tools
 
+<details>
+<summary><strong>Use Impeccable design guidance</strong></summary>
+
+Choose **/hybrid → Design guidance → Impeccable**. Nothing else needs installing.
+
+![Choose Impeccable inside OpenCode](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@1.1.0/docs/images/22-design-guidance.png)
+
+For one task, ask **“Use Impeccable to redesign this page”**, or use `/hybrid-impeccable polish the checkout`.
+
+This supplies Impeccable's design guidance to your selected premium lead and reviewers. It does not run Impeccable's separate engine, hooks or audit commands. [Supported scope](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@1.1.0/docs/impeccable.md).
+
+</details>
+
 <details>
 <summary><strong>Let reviewers inspect your app in a browser</strong></summary>
 
@@ -125,7 +140,7 @@ Confirm installation of Playwright and Firefox.
 
 ![Confirm browser installation](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@0.3.2-beta.3/docs/images/11-browser-confirm.png)
 
-Each reviewer gets an isolated browser for a captured frontend and disposable API fixtures. Ask the agent to add [repeatable browser checks](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@1.0.0/docs/browser-evidence.md). Live backend testing stays with your application's integration tests.
+Each reviewer gets an isolated browser for a captured frontend and disposable API fixtures. Ask the agent to add [repeatable browser checks](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@1.0.1/docs/browser-evidence.md). Live backend testing stays with your application's integration tests.
 
 ![Browser support installed](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@0.3.2-beta.3/docs/images/12-browser-ready.png)
 
@@ -175,10 +190,10 @@ Remove the old plugin entries from `opencode.json` and `cli.json` before adding
 
 </details>
 
-[Advanced configuration](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@1.0.0/docs/configuration.md) · [MIT license](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@1.0.0/LICENSE) · [Third-party notices](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@1.0.0/THIRD_PARTY_NOTICES.md)
+[Advanced configuration](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@1.0.1/docs/configuration.md) · [MIT license](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@1.0.1/LICENSE) · [Third-party notices](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@1.0.1/THIRD_PARTY_NOTICES.md)
 
-For deterministic Vitest projects, see [faster verification](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@1.0.0/docs/verification.md). Full checks remain the default; eligible projects automatically choose full checks when measured optimization overhead is higher.
+For deterministic Vitest projects, see [faster verification](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@1.0.1/docs/verification.md). Full checks remain the default; eligible projects automatically choose full checks when measured optimization overhead is higher.
 
-[Repeatable browser checks](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@1.0.0/docs/browser-evidence.md) capture changed frontend states once for both reviewers, while keeping their independent inspections and approval decisions.
+[Repeatable browser checks](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@1.0.1/docs/browser-evidence.md) capture changed frontend states once for both reviewers, while keeping their independent inspections and approval decisions.
 
-[Engineering handoffs](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@1.0.0/docs/engineering-handoffs.md) give implementation agents concrete responsibility and state ownership. Reviewers check the code against the plan; small changes keep existing patterns, with no file-length limits or extra planning phase.
+[Engineering handoffs](https://cdn.jsdelivr.net/npm/@rockysoft/opencode-hybrid-workflow@1.0.1/docs/engineering-handoffs.md) give implementation agents concrete responsibility and state ownership. Reviewers check the code against the plan; small changes keep existing patterns, with no file-length limits or extra planning phase.

package/THIRD_PARTY_NOTICES.md

@@ -18,3 +18,8 @@ their respective files; the root license does not replace them. No user
 credentials, project memories, session logs or runtime reports are included.
 
 - Runtime dependency `diff` (jsdiff) 9.0.0, BSD-3-Clause, https://github.com/kpdecker/jsdiff. Its license is distributed with the dependency.
+# Impeccable guidance
+
+Selected unmodified Markdown references from Impeccable 4.8.0 by Paul Bakaus and contributors, commit `9fadc41729c38fd47d7ae622b501558653f9d2e9`, https://github.com/pbakaus/impeccable.
+Licensed under Apache-2.0; full license and provenance are in `assets/integrations/impeccable/`. The upstream executable engine, hooks and command runner are not included.
+

package/assets/integrations/impeccable/LICENSE

@@ -0,0 +1,191 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to the Licensor for inclusion in the Work by the copyright
+      owner or by an individual or Legal Entity authorized to submit on
+      behalf of the copyright owner. For the purposes of this definition,
+      "submitted" means any form of electronic, verbal, or written
+      communication sent to the Licensor or its representatives, including
+      but not limited to communication on electronic mailing lists, source
+      code control systems, and issue tracking systems that are managed by,
+      or on behalf of, the Licensor for the purpose of discussing and
+      improving the Work, but excluding communication that is conspicuously
+      marked or otherwise designated in writing by the copyright owner as
+      "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   Copyright 2025 Paul Bakaus
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/assets/integrations/impeccable/NOTICE.md

@@ -0,0 +1,11 @@
+# Third-Party Notices
+
+This project includes content derived from third-party work, used under the terms of its original license.
+
+## Platform Design Skills
+
+The `skill/reference/ios.md` and `skill/reference/android.md` platform reference files are distilled from ehmo's `platform-design-skills` (Apple Human Interface Guidelines and Material Design 3 rules), rewritten in Impeccable's voice.
+
+**Original work:** https://github.com/ehmo/platform-design-skills
+**Original license:** MIT
+**Author:** ehmo

package/assets/integrations/impeccable/colorize.md

@@ -0,0 +1,86 @@
+> **Additional context needed**: existing brand colors.
+
+Introduce color as hierarchy, meaning, and atmosphere. Preserve confirmed brand and semantic conventions; do not replace a visual world under the guise of colorizing it.
+
+---
+
+## Visitor mode
+
+- **Persuade + Experience:** color may carry the voice and own large regions when the selected world calls for it.
+- **Operate + Read:** color primarily encodes action, selection, status, wayfinding, and reading hierarchy. Rarity gives an accent force.
+
+## Audit before choosing
+
+Read DESIGN.md, tokens, assets, current themes, and representative states. Identify:
+
+- which colors are confirmed brand commitments;
+- current surface, text, action, and semantic roles;
+- places where grayscale obscures hierarchy or state;
+- contrast failures and color-only communication;
+- light/dark or data-visualization requirements;
+- whether the task asks for more color or a new identity.
+
+If a new identity is required, use [new-work.md](new-work.md). Ask only when a binding brand decision cannot be inferred.
+
+## Choose a strategy
+
+Name the intended emotional temperature, dominant relationship, contrast range, and color dosage before editing. The strategy may be restrained or immersive; it must follow the brief and selected world rather than a fixed percentage rule.
+
+Build roles, not a bag of swatches:
+
+- canvas and elevated surfaces;
+- primary and secondary text;
+- action, focus, and selection;
+- borders and separators;
+- success, warning, error, and information;
+- data categories or scales when needed.
+
+Use the project's existing color space. For a new web palette, prefer OKLCH because lightness and chroma can be adjusted predictably. Choose hue from product meaning and visual direction, never from a default category association.
+
+## Apply at system scale
+
+- Let the strongest color own a deliberate region or role instead of scattering tiny accents.
+- Keep the primary action easy to find; do not spend its color on decoration.
+- Tint neutrals only when the brand hue genuinely creates cohesion. Neutral gray is valid when it serves the world.
+- On colored surfaces, derive secondary text from the foreground or surface hue rather than using washed-out generic gray.
+- Keep semantic meanings consistent, but respect platform and domain conventions instead of assuming fixed hues.
+- For data, use distinct lightness, chroma, shape, label, or pattern so color is not the only code.
+- In dark mode, design surface elevation and contrast explicitly; do not invert the light theme mechanically.
+- Define primitive values and semantic tokens when the project has a token system. Theme changes should normally remap semantic roles.
+
+Decoration without a relationship to hierarchy, state, content, or the visual world is not a color strategy.
+
+## Contrast and perception
+
+Verify computed foreground/background pairs:
+
+| Content | WCAG AA minimum |
+|---|---|
+| body text | 4.5:1 |
+| large text | 3:1 |
+| controls, icons, focus indicators | 3:1 |
+
+Do not rely on eyesight alone. Check interactive states, overlays, text on images, disabled content, and both themes. Simulate common vision deficiencies. Information conveyed by color also needs text, shape, iconography, or position.
+
+When deriving OKLCH ramps, vary lightness and reduce chroma near white and black. Do not keep high chroma at extreme lightness merely to make the math uniform. Prefer explicit colors over chains of translucent overlays when alpha would make contrast context-dependent.
+
+## Verify
+
+- Every color has a stable role or a world-specific atmospheric purpose.
+- Attention lands on the intended action, content, or state.
+- The palette works across quiet, dense, interactive, error, and empty states.
+- Light and dark themes are each composed, not mechanically inverted.
+- Contrast and non-color cues pass in all relevant states.
+- The result is recognizably this product, not a generic “colorful” treatment.
+
+When the palette earns its place, hand off to `/impeccable polish` for the final pass.
+
+## Live-mode signature params
+
+When invoked from live mode, every variant declares a `color-amount` parameter. Author CSS against `var(--p-color-amount, 0.5)` so the user can move from neutral to the variant's full color strategy without regeneration.
+
+```json
+{"id":"color-amount","kind":"range","min":0,"max":1,"step":0.05,"default":0.5,"label":"Color amount"}
+```
+
+Add at most two variant-specific parameters, such as palette, temperature, or tint behavior. Follow [live.md](live.md)'s parameter contract.

package/assets/integrations/impeccable/craft-floor.md

@@ -0,0 +1,44 @@
+# Craft floor
+
+Load this after the direction is settled, and build without announcing the checklist. A pinned brief or the committed visual world overrides anything here except a line marked as a ban; your own habit does not. When the design hook is active it already enforces the mechanical checks below as you edit: act on its findings instead of re-auditing each rule.
+
+## Verify
+
+Each of these is a check on the built result, not an intention. Run them together in each batched look at the render, not as separate screenshot trips; the checks share one render.
+
+- **Contrast:** body and placeholder text ≥4.5:1, large text ≥3:1. On colored surfaces tint secondary text from that hue or the foreground; never gray.
+- **Depth:** shadows carry an offset and a soft blur. A zero-offset colored halo is decoration.
+- **Spacing:** tight groups, generous separation, more space above a heading than below it. Read the computed values.
+- **Type:** body measure 65–75ch, display max 6rem, tracking floor -0.04em, balanced headings, obvious scale and weight steps. Run the real copy at every breakpoint and fix what overflows.
+- **Motion:** one authored moment, not scattered effects and not one identical entrance on every section. Exponential ease-out from an already-visible default. Reach past transform and opacity: blur, backdrop-filter, clip-path, mask, and shadow belong to the palette when they stay smooth.
+- **States:** hover, disabled, loading, error, empty. Plus real content, working controls, responsive composition, keyboard focus.
+- **Browser surfaces:** the parts you did not draw still carry the design. Text selection, the caret, custom scrollbars, focus rings, underline offset, and the numerals in tabular data all ship with browser defaults that belong to no design system. Theme them from the palette. This is the cheapest signal that a page was built rather than assembled, and the one models skip most reliably.
+- **Copy:** the product's own language. Controls name their action; errors name the problem and the recovery.
+- **Coverage:** every brief requirement present and findable within seconds.
+
+## Refuse
+
+These are the category's defaults, not bans: the brief's own words can earn any of them. Reaching for one when the axis is free means you were not deciding; recognizing that means rewriting the element, not softening it.
+
+Page scaffolds:
+
+- Same-size cards of icon plus heading plus text as the page structure. Cards are the lazy container; nested cards are always wrong.
+- The hero-metric template: big number, small label, supporting stats, accent.
+- A kicker or eyebrow above a heading. This one is a ban, not a default: no brief earns it back. The heading carries its own weight; delete the label and let the heading speak.
+- Section numbers (01 / 02 / 03) unless the sequence itself carries information the reader needs.
+- A modal for a task that needs neither interruption nor protected focus.
+
+Surface habits:
+
+- Gradient text. Emphasis comes from weight or size.
+- Glass and blur as decoration rather than as a specific effect.
+- A colored `border-left` or `border-right` above 1px on cards, list items, callouts, or alerts.
+- Hard offset shadows (`box-shadow: 4px 4px 0`) outside a world that is actually neobrutalist. The zero-blur block shadow is a costume, not a depth system; a world that did not choose it never earns it as a default.
+- Sparklines, progress rings, and soft-shadowed rounded rectangles standing in for content.
+- Monospace as a costume for "technical" rather than for code, data, or measurement.
+- A system display face (Impact, Arial Black, the platform sans) as the display voice of an own-world page. Source and self-host a face whose character matches the approved lettering; the closest installed font is a failure, not a fallback.
+- Unicode glyphs or emoji standing in for an icon system. Icons are drawn, from a real library or authored SVG, in one consistent stroke and weight.
+- Geometric masks standing in for organic contours. A circle, polygon, or radial-gradient cutout approximating a photographic subject's edge is the cheap version of the effect and reads worse than omitting it. Derive an alpha matte from the actual image, or produce a cut-out asset.
+- Light or dark picked by category. Pick it from the use scene: who, where, under what ambient light.
+
+The floor holds the mechanics; it never picks the direction. With every check green, spend the page on the committed world, and when torn between refined and committed, commit.

package/assets/integrations/impeccable/layout.md

@@ -0,0 +1,84 @@
+Layout turns product priority into reading order, grouping, rhythm, and usable space. Diagnose the structural problem before moving boxes.
+
+---
+
+## Visitor mode
+
+- **Persuade + Experience:** composition may be asymmetric, fluid, or intentionally disruptive when the selected world earns it.
+- **Operate + Read:** predictable structure, stable density, and navigable linearity are affordances.
+- **Native:** follow [ios.md](ios.md) or [android.md](android.md) for navigation, insets, adaptation, and touch targets.
+
+Preserve the established visual world. A layout command changes structure inside it; identity replacement belongs to [new-work.md](new-work.md).
+
+## Two isolated assessments
+
+When a sub-agent tool is available and permitted, run these independently; otherwise run them yourself in this order.
+
+1. **Layout assessment:** inspect representative states and viewports. Answer every question below with rendered or source evidence:
+   - **Reading order:** Apply the squint test. With detail blurred, can you still identify the primary element, the secondary element, and the major groups in order?
+   - **Grouping:** Are related items close and distinct groups separated, or are containers compensating for weak proximity?
+   - **Rhythm:** Do tight and generous intervals create a deliberate cadence, or is one spacing value repeated until everything has equal weight?
+   - **Structure:** Does the topology match the content and task? Are repeated cards, columns, or sections genuinely equivalent, or merely a framework default?
+   - **Density:** Does the amount of information per region fit use frequency, decision complexity, and visitor mode?
+   - **Adaptation:** At narrow, intermediate, wide, zoomed, and localized states, what reorders, collapses, wraps, scrolls, or remains fixed? Does DOM and focus order still agree with the visual order?
+   - **Extremes:** Do long content, empty states, overlays, sticky elements, safe areas, and small touch targets expose structural failures?
+2. **Mechanical scan:** run:
+
+```bash
+.opencode/skills/impeccable/scripts/impeccable detect --json --scope layout [target files or dirs]
+```
+
+Also inspect arbitrary spacing, overflow, stacking, and container behavior the detector cannot resolve. Keep mechanical evidence out of the first assessment, then synthesize both passes before editing. A clean scan cannot prove hierarchy or rhythm.
+
+## Set the spatial thesis
+
+Before editing, name:
+
+- the primary reading or task path;
+- what belongs together and what must separate;
+- which element leads and which supports;
+- the intended density and spacing rhythm;
+- how the structure changes across containers, viewports, input modes, and content extremes.
+
+Choose the simplest structural model that expresses those relationships. Use layout primitives according to the relationships they control, and name reusable spacing and container roles semantically.
+
+## Apply
+
+- Group by meaning. Use proximity before adding containers or decoration.
+- Create rhythm through deliberate contrast between tight and generous intervals.
+- Use a documented spacing scale rather than one-off values. A 4-unit base usually provides the useful middle steps that an 8-only scale misses.
+- Let hierarchy follow product priority, not framework defaults.
+- Keep distinct content visually distinct without turning every group into an isolated component.
+- Make responsive behavior structural: reorder, collapse, reflow, or reveal based on what remains important.
+- Prefer container-aware components when the same component appears in different contexts.
+- Use `gap` for sibling rhythm when it expresses the relationship more directly than child margins.
+- Keep touch targets usable even when their visible marks are small.
+- Use depth only when it clarifies state or hierarchy.
+- Make optical corrections only after inspecting the rendered result.
+
+Variation is not a goal by itself. Repetition should support recognition; break it only when content or priority changes.
+
+## Verify
+
+- The squint test still reveals the primary, secondary, and major groups in order.
+- The reading and task path remains clear at every supported size.
+- Related content groups naturally; unrelated content does not blur together.
+- Tight and generous spacing create intentional rhythm instead of monotonous repetition.
+- Density matches use frequency and content complexity.
+- Long text, empty states, localization, zoom, and dynamic content do not break the structure.
+- Keyboard, touch, and assistive-technology order agree with the visual order.
+- The final mechanical scan has no unexplained findings.
+
+Answer each item with rendered or source evidence, then rerun the scan. Do not substitute a bare “yes” for verification.
+
+When the structure holds, hand off to `/impeccable polish`.
+
+## Live-mode signature params
+
+Every variant declares a coarse `density` parameter and authors spacing against `var(--p-density, 1)`.
+
+```json
+{"id":"density","kind":"range","min":0.6,"max":1.4,"step":0.05,"default":1,"label":"Density"}
+```
+
+Add one structural parameter only when the topology genuinely branches. Follow [live.md](live.md)'s parameter contract.

package/assets/integrations/impeccable/polish.md

@@ -0,0 +1,105 @@
+> **Additional context needed**: quality bar and shipping constraints.
+
+Polish is refinement, never concealed redesign. Preserve the incumbent visual world, content, behavior, and everything outside scope. If the concept itself is wrong, say so and recommend redesign or `bolder` instead of smuggling in a replacement.
+
+A detector result is defect evidence, not proof of quality. Inspect the rendered experience and real interaction path.
+
+## 1. Establish the system
+
+Read DESIGN.md and representative tokens, shared components, patterns, and neighboring flows. If no formal system exists, use coherent project conventions.
+
+Classify each drift before fixing it:
+
+- **missing token:** the system needs a reusable value;
+- **one-off implementation:** an existing shared component or pattern should replace it;
+- **conceptual mismatch:** the flow, information architecture, or hierarchy differs from comparable product areas;
+- **local defect:** the implementation is simply incomplete or inconsistent.
+
+Fix the cause at the narrowest correct level. Ask when a binding system principle cannot be inferred.
+
+## 2. Gather the evidence
+
+Use the feature yourself at the surface's representative sizes: desktop and mobile on the web; on a native platform (`ios` / `android` / `adaptive`), the shipped device classes on the simulator, emulator, or hardware, captured per the platform reference's Verifying the build section. Determine:
+
+- whether the path is functionally complete;
+- the intended quality bar and time available;
+- known constraints or deliberately unfinished work;
+- the states, content lengths, roles, and input methods users will actually encounter.
+
+If a prior critique exists, use it as one input:
+
+```bash
+.opencode/skills/impeccable/scripts/impeccable critique-storage latest "<resolved target>" --json
+```
+
+Exit 0 returns JSON with the latest snapshot's `body` and an exact `snapshot_file` identity. Retain `snapshot_file` until the end of the pass. For a local file target, the helper compares the file's exact current content fingerprint with the fingerprint captured by critique. Unchanged staged, unstaged, or untracked content remains current; any byte change, deletion, or replacement with a non-file closes the backlog it identified while preserving its trend history and exits 2. A URL target has no local fingerprint and remains current until explicitly closed. When current, incorporate relevant P0/P1 findings from `body` and name the snapshot read. Exit 2 means none exists or the target changed. Perform an independent pass either way.
+
+## 3. Triage
+
+Separate functional defects from cosmetic ones and fix in this order:
+
+1. broken or blocked tasks, data loss, misleading state, and inaccessible paths;
+2. missing loading, empty, error, success, disabled, and permission states;
+3. flow, hierarchy, responsive, and design-system drift;
+4. visual and motion inconsistencies;
+5. code and asset cleanup.
+
+Do not perfect one corner while leaving the rest below the same quality bar.
+
+## 4. Polish the whole path
+
+### Flow and hierarchy
+
+- Match neighboring mental models, terminology, disclosure, routing, save behavior, and optimistic or pessimistic patterns.
+- Make the primary task and current state obvious without flattening every element to equal weight.
+- Ensure arrival, transition, empty, and recovery paths connect instead of behaving as isolated screens.
+
+### Layout and type
+
+- Align to the project's grid and spacing scale; fix optical as well as mathematical alignment.
+- Group related content tightly and separate distinct groups generously.
+- Keep same-role typography consistent; test measure, wrapping, localization expansion, zoom, and font loading.
+- Verify every supported viewport rather than correcting only the current screenshot.
+
+### Color, imagery, and icons
+
+- Use semantic tokens and stable color meanings across themes.
+- Verify text, control, and focus contrast in every state.
+- Keep icon families, stroke/weight, sizing, and optical alignment coherent.
+- Prevent image layout shift; use correct aspect ratios, responsive sources, and useful alt text.
+
+### Interaction and state
+
+- Every control needs appropriate default, hover, focus, active, disabled, loading, error, and success behavior.
+- Preserve visible keyboard focus, logical tab order, labels, and platform-appropriate touch targets.
+- Keep motion coherent, interruptible, and performant. Do not add animation merely to make polish visible.
+- Validate long, missing, localized, offline, slow, and permission-limited content where the product can encounter it.
+
+### Content and code
+
+- Keep terminology, capitalization, punctuation, and factual copy consistent. Ask before changing claims.
+- Remove debug output, dead code, unused imports, obsolete styles, and polish-created duplication.
+- Replace custom implementations with shared components where the system owns the pattern.
+- Promote genuinely reusable values to tokens; do not create a system abstraction for one local exception.
+
+## 5. Verify and finish
+
+Walk the complete path again with mouse, keyboard, and touch where applicable. Check:
+
+- mobile, intermediate, and wide layouts on the web; phone and tablet size classes in both supported orientations on native;
+- loading, empty, error, success, disabled, long-content, and missing-content states;
+- zoom, contrast, focus, semantics, and screen-reader names;
+- console errors, layout shift, interaction latency, and image loading everywhere; supported browsers on the web; supported OS versions, runtime warnings, and dropped frames on native;
+- agreement with DESIGN.md, neighboring features, and the user's scope.
+
+Follow the quality guidance supplied by `impeccable context` and hooks, then run any other relevant QA commands. Context requests a manual scan only when no automatic detector is active; never add another detector pass. Fix real defects and document only narrow intentional exceptions. A clean scan does not replace visual judgment.
+
+Finish with a source diff: remove accidental churn, orphaned code, redundant values, and temporary artifacts. Ship only when the feature is functionally complete and consistently finished across the path.
+
+When this pass clears every Priority Issue it took from a snapshot, close that snapshot:
+
+```bash
+.opencode/skills/impeccable/scripts/impeccable critique-storage close "<resolved target>" "<snapshot_file returned by latest>"
+```
+
+This closes only the snapshot this pass actually processed; if a newer critique landed meanwhile, its backlog stays live. Do not close when no snapshot was read, when `snapshot_file` was not retained, or when Priority Issues remain.

package/assets/integrations/impeccable/provenance.json

@@ -0,0 +1,8 @@
+{
+  "project": "Impeccable",
+  "license": "Apache-2.0",
+  "commit": "9fadc41729c38fd47d7ae622b501558653f9d2e9",
+  "scope": "Unmodified selected Markdown references; upstream executable engine and hooks are not bundled.",
+  "version": "4.8.0",
+  "source": "https://github.com/pbakaus/impeccable"
+}

package/assets/integrations/impeccable/typeset.md

@@ -0,0 +1,90 @@
+Typography carries information, hierarchy, and voice. Improve it inside the established visual world; do not replace the identity unless the user asked to.
+
+---
+
+## Visitor mode
+
+- **Persuade + Experience:** display type may carry the voice. Use decisive contrast and responsive scale when the composition benefits.
+- **Operate + Read:** stability, scanability, and measure come first. A single well-tuned family and fixed role scale are often right.
+- **Native:** follow [ios.md](ios.md) or [android.md](android.md), including platform scaling and accessibility behavior.
+
+If typography replacement would create a new identity, route through [new-work.md](new-work.md) and update DESIGN.md. Otherwise preserve confirmed families and improve their use.
+
+## Two isolated assessments
+
+When a sub-agent tool is available and permitted, run these independently; otherwise run them yourself in this order. Do not let detector findings anchor the design assessment.
+
+1. **Typographic assessment:** inspect representative pages and styles. Answer every question below with a file, selector, or computed value:
+   - **Authority and fit:** Which faces, weights, and roles are established? Do they fit the product and selected world, or are they unexamined defaults? Is every family necessary?
+   - **Hierarchy:** Can heading, body, label, metadata, and data roles be distinguished at a glance? Are adjacent sizes or weights too close to carry different jobs?
+   - **Scale and consistency:** Is there a deliberate role scale, or a collection of arbitrary values? Do repeated roles stay identical across screens and states?
+   - **Reading:** Does body copy stay within a comfortable 45–75 character measure? Are line height, paragraph rhythm, contrast, and tracking tuned to the actual face, width, language, and surface?
+   - **Stress:** What happens with long headings, localization expansion, zoom, narrow containers, missing weights, and font fallback?
+   - **Delivery:** Are only used assets loaded? Do fallback metrics, loading strategy, and variable-font settings avoid invisible text and disruptive reflow?
+2. **Mechanical scan:** run:
+
+```bash
+.opencode/skills/impeccable/scripts/impeccable detect --json --scope type [target files or dirs]
+```
+
+Also inspect dynamic or arbitrary font values the detector cannot interpret. Synthesize both assessments before editing, noting what each caught alone. A clean scan is a floor, not proof of good typography.
+
+## Set the system
+
+Before editing, state:
+
+- the roles the interface needs;
+- the intended contrast between those roles;
+- the reading measure and density;
+- which existing faces and weights are authoritative;
+- any performance, localization, or accessibility constraints.
+
+Use the fewest roles and families that make the hierarchy unmistakable. Combine size, weight, space, and tone deliberately instead of asking size alone to do all the work. Role names and tokens should describe purpose rather than values.
+
+## Apply
+
+- Keep body copy comfortably readable and zoomable. Use 1rem / 16px as the ordinary web body floor unless a dense role, platform convention, or user setting justifies otherwise.
+- Keep prose in the 45–75ch range. Tune line height inversely with measure: wider lines generally need more leading.
+- Compensate light text on dark surfaces on all three perceptual axes: slightly more line height, a touch more tracking, and one step more weight when the face needs it.
+- Tune line height to the face, width, language, and contrast, not a universal ratio.
+- Keep repeated roles consistent across screens and states.
+- Use numeric, tabular, code, and label features when their content benefits.
+- Load only used font assets and weights. Provide metric-compatible fallbacks and avoid blocking text.
+- Let marketing display type respond to available space when useful; keep dense product and reading surfaces spatially predictable.
+- Preserve browser zoom, user font settings, Dynamic Type, and platform text scaling.
+- Use paragraph spacing or first-line indentation as the primary paragraph rhythm; combining both usually double-marks the boundary.
+
+Do not make type decorative at the expense of comprehension, or introduce a second family without a clear role it alone can perform.
+
+## Line breaks
+
+After Matthew Butterick's *Practical Typography*, paraphrased; where his numbers differ from these, these stand.
+
+- Set `text-wrap: balance` on headings and short centered blocks, and `text-wrap: pretty` on body copy. Both are progressive: a browser that ignores them keeps its default wrap.
+- `pretty` pulls a word down beside a lone last word. It does not fill the last line, and a two-word tail is fine.
+- In a column too narrow for either to help, edit the copy or widen the column.
+- Break a heading by hand only between phrases, and check the break at every width the heading renders at. A hard break that lands mid-line on a phone is worse than the default wrap.
+- An uneven break can carry meaning: a headline that lands on one word for weight, a poster line, a pull quote. Make it deliberate with a hard break or a wrap set on that element, and keep it rare. The detector's `straggler` and `unbalanced-heading` findings are advisory for this reason; say which breaks are intended.
+
+## Verify
+
+- Primary, secondary, body, and metadata roles are recognizable without reading the copy.
+- Long text remains comfortable across relevant widths and languages.
+- The typography belongs to the product and its established world.
+- Loading does not create disruptive reflow or invisible text.
+- Zoom, text scaling, focus, contrast, and reduced viewport paths remain usable.
+- The final mechanical scan has no unexplained findings.
+
+Answer each item with rendered or source evidence, then rerun the scan. Do not substitute a bare “yes” for verification.
+
+When the hierarchy holds, hand off to `/impeccable polish`.
+
+## Live-mode signature params
+
+Every variant declares a coarse `scale` parameter and authors its type ramp against `var(--p-scale, 1)`.
+
+```json
+{"id":"scale","kind":"range","min":0.85,"max":1.3,"step":0.05,"default":1,"label":"Scale"}
+```
+
+Add at most one pairing or weight parameter when it represents a real system choice. Follow [live.md](live.md)'s parameter contract.

package/core/controller.mjs

@@ -40,7 +40,7 @@ For UI implementation reviews compare the supplied approved Claude design or est
 For planning report a concrete plan: requirements, responsibility boundaries, contracts, alternatives/tradeoffs, security, data handling, investigation points, specialist-owned slices, acceptance checks and relevant design skills.
 For author/proposal/synthesis stages, pass means your proposed document is ready for independent validation, not implementation approval. Do not use revise merely because you rewrote a plan: revise requires a concrete open finding and blocked requires a material open finding.
 Architecture planning precedes design for new applications and substantive behavior/architecture changes; existing-app visual redesigns use mode=ui and go directly to design. Claude/Opus owns new UI/UX design, using the supplied design skills and research; Astra reviews the exact design. Never assign new design decisions to the implementation model or its frontend agent. Existing/supplied design patterns may be implemented faithfully without a new design phase. Architecture approval alone is not visual-design approval. Do not block architecture planning because later design artifacts do not exist yet. The reviewer CLI receives captured skill evidence rather than OpenCode's native skill catalog.
-New websites/redesigns must use frontend-design and ui-ux-pro-max before implementation, and web-design-guidelines for review. Use pnpm where appropriate; honor installed versions and project rules.
+New websites/redesigns must use the supplied design guidance before implementation. When the packet selects Impeccable, its bundled references replace frontend-design/ui-ux-pro-max research for this checkpoint; follow its integration policy, not upstream executable workflow or delegation commands. Otherwise use frontend-design and ui-ux-pro-max before implementation, and web-design-guidelines for review. Use pnpm where appropriate; honor installed versions and project rules.
 You may read files under source/ and the packet. Never search the web with private source or internal URLs. No commands that change anything. Keep reports concise and proportional to risk. Missing evidence must be explicit.
 ${WORKFLOW_POLICY}`;
 

package/core/design.mjs

@@ -6,10 +6,12 @@ import { runProcess } from './workers.mjs';
 import { captureImages } from './images.mjs';
 import {findingChecklist,findingDecision} from './findings.mjs';
 import {browserEvidence} from '../lib/browser-evidence/receipt.mjs';
+import {impeccableIntent,impeccableEvidence} from '../lib/impeccable.mjs';
 
 export const DESIGN_POLICY = `UI/UX ownership: the implementation model must not invent visual direction or interaction design. Claude/Opus authors new design decisions and Astra reviews them. This applies to new projects, substantial features without a design, and later redesign/improve-UI requests. Small/medium additions can reuse an established design system and supplied Figma/Claude/local designs can be implemented faithfully, with concrete reference evidence. Escalate material gaps instead of filling them with your own design. Before edits call hybrid_checkpoint design when design is pending; do not bypass through subagents. Read the returned approved design document and give it to frontend-engineer. Existing/supplied exceptions require designMode and designEvidence at begin. Architecture planning does not authorize new visual decisions.`;
 
 export function designIntent(text = '') {
+  if(impeccableIntent(text))return 'new';
   // This is an admission safety net, not a substitute for the semantic routing rule.
   const value = text.toLowerCase().replace(/\b(?:do not|don't|without|no)\s+(?:re-?design|redesign|redisign)\b/g, 'preserve');
   const supplied = /\b(figma|supplied design|provided design|claude design|design file|reference design)\b/.test(value) && /\b(implement|match|follow|reproduce|replicate)\b/.test(value);
@@ -85,6 +87,8 @@ export async function design(state, input, signal) {
   const brief = pending.length ? pending.map(r=>r.text).join('\n\n') : state.brief;
   const evidence = {brief, userDirections:pending, plan:state.plan, referenceEvidence:state.designEvidence ?? '', supplied:input.checks ?? ''};
   const tree = snapshot(this.directory);
+  const integration=impeccableEvidence(this.config,brief,tree);
+  if(integration)evidence.impeccable={name:integration.name,mode:integration.mode,provenance:integration.provenance,digest:integration.digest};
   const captured=browserEvidence(this,state,tree.fingerprint);
   const images=[...captureImages(this.directory,input.images,tree.fingerprint),...captured.images].map((image,index)=>({...image,manifest:{...image.manifest,path:`images/${index}.png`}}));
   evidence.browserEvidence=captured.summary;
@@ -95,7 +99,7 @@ export async function design(state, input, signal) {
   state.designResumePhase ??= ['fix','review'].includes(state.phase) ? 'fix' : 'implement';
   if(state.mode==='cosmetic') state.mode='small';
   state.phase='design'; this.save(state);
-  const skills = await (this.designEvidence ?? skillEvidence)(this,brief,state.mode === 'small');
+  const skills = integration ? {impeccable:integration,guidance:integration.policy} : await (this.designEvidence ?? skillEvidence)(this,brief,state.mode === 'small');
   if (state.designEvidenceHash !== evidenceHash) { state.designNeedsRevision=true; state.designEvidenceHash=evidenceHash; delete state.designPause; }
   while (true) {
     if(signal?.aborted) throw new Error('Design cancelled; approval remains closed.');

package/core/plugin.mjs

@@ -8,6 +8,7 @@ import { Controller } from './controller.mjs';
 import { readDashboard } from './monitor-data.mjs';
 import { DESIGN_POLICY, recordDesignRequest } from './design.mjs';
 import { researchTool } from './research-tools.mjs';
+import {registerImpeccableCommand,IMPECCABLE_POLICY} from '../lib/impeccable.mjs';
 
 const here = path.dirname(fileURLToPath(import.meta.url));
 // V2's Plugin.define is an identity function. This plain plugin needs no installed dependencies.
@@ -20,6 +21,7 @@ export function createPlugin(config, storage = config.runtimeDirectory ?? path.j
     const compatible = config.compatibleOpenCode ?? [config.targetOpenCode];
     if (!compatible.includes(ctx.app.version)) throw new Error(`Hybrid plugin compatibility check required: running OpenCode ${ctx.app.version}; verified versions: ${compatible.join(', ')}. Run the isolated compatibility probe before adding this version. Existing task history is preserved.`);
     const controllers = new Map();
+    await registerImpeccableCommand(ctx);
     const forSession = async sessionID => {
       const result = await ctx.session.get({ sessionID });
       const session = result.data ?? result;
@@ -40,6 +42,7 @@ export function createPlugin(config, storage = config.runtimeDirectory ?? path.j
       if(await isReviewerSession(ctx,event.sessionID))return;
       event.system.push({type:'text',text:roleText(DESIGN_POLICY)});
       event.system.push({type:'text',text:roleText(WORKFLOW_POLICY)});
+      event.system.push({type:'text',text:IMPECCABLE_POLICY});
       event.system.push({type:'text',text:`${FRONTEND_COMMON}\n${FRONTEND_BUILD}`});
       event.system.push({type:'text',text:'Hybrid recovery: completed negative/blocked code reviews allow corrections and evidence collection in fix; continue automatically and re-review, never claim acceptance. action=fix recovers a legacy completed review. New evidence in checks/images resumes paused plan/design; action=replan with concrete changed requirements opens architecture revision while preserving findings and history. action=inspect checks installed tools and CLI logins without model calls and is available during planning. Never edit bridge state or reset history. Playwright research outputs use plain filenames in .playwright-mcp/hybrid-evidence; this generated evidence is excluded from source snapshots. Navigation/resizing and screenshot capture are available while planning/designing. Supply actual PNGs to plan/design/review as images [{path,caption,artifactHash}], using status.currentArtifactHash for the code/reference being inspected. Recapture after code changes and include interaction evidence in checks. Both reviewers receive pixels; never substitute hashes or ask the user to attest images merely because they live outside Git.'});
     });

package/docs/CHANGELOG.md

@@ -1,5 +1,17 @@
 # Release notes
 
+## 1.1.0
+
+- Add optional Impeccable design guidance in Hybrid settings and `/hybrid-impeccable redesign` or `polish`. The configured design lead authors the direction, reviewers validate it, and the implementation model follows the approved document.
+- Bundle selected, version-pinned Impeccable references with their license. No separate engine, hooks or runtime downloads are required.
+- Recover interrupted native-provider reports as complete responses instead of accepting a continuation fragment. Incomplete recovery still blocks approval.
+- Accept an exact single JSON code-block wrapper from native reviewers while retaining strict response validation.
+
+## 1.0.1
+
+- Refresh usage sidebar settings immediately after saving Hybrid setup, including reviewer models, effort, reviewer count and telemetry location. No restart is needed for these sidebar changes.
+- Discard reads from the previous settings so late results cannot replace the refreshed display.
+
 ## 1.0.0
 
 - Carry reviewed project ownership hints into subsequent tasks, with project/source bindings and automatic invalidation when files change. Hints never replace source inspection or approval.

package/docs/impeccable.md

@@ -0,0 +1,22 @@
+# Impeccable design guidance
+
+In **/hybrid → Design guidance**, select **Impeccable**. Your selected design lead and reviewers stay in charge. Nothing else needs installing.
+
+![Select design guidance inside OpenCode](images/22-design-guidance.png)
+
+For a single task, use:
+
+```text
+/hybrid-impeccable redesign the portfolio
+/hybrid-impeccable polish the checkout
+```
+
+Or ask normally: “Use Impeccable to redesign this page.” Say “without Impeccable” to override the global setting for a request.
+
+The lead receives selected Impeccable references and existing project design documents, authors concrete implementation instructions, and submits them to the configured reviewers. Your implementation model follows the approved document. Polish preserves the current identity; redesign can replace it. The existing rule still applies: all configured reports, at least one pass, and no unresolved medium/high/critical findings.
+
+This integrates **Impeccable 4.8.0 design guidance**, not its separate executable engine. It does not install or run upstream hooks, detectors, live mode, concept boards, image generation or audit commands. Those tools' results are never implied by using the guidance. `/hybrid-impeccable` is separate from an independently installed `/impeccable` command; use the Hybrid command for this workflow.
+
+The setting affects future design checkpoints without invalidating existing approvals or changing reviewers on active tasks. The command is available on hosts with OpenCode's command transform API; normal chat routing remains available on other supported OpenCode 2 hosts.
+
+Bundled references carry their original license and exact source commit in `assets/integrations/impeccable/`. No third-party scripts or runtime downloads are required. Relevant project documents come from the same sanitized snapshot as the source evidence.

package/lib/config.mjs

@@ -34,6 +34,7 @@ export function readSettings(options={},env=process.env) {
   const config={...defaults,...supplied,reviewers:Object.fromEntries(['astra','opus'].map(who=>[who,supplied.reviewers?.[who]===null?null:supplied.reviewers?.[who]?.adapter&&supplied.reviewers[who].adapter!==defaults.reviewers[who].adapter?supplied.reviewers[who]:{...defaults.reviewers[who],...supplied.reviewers?.[who]}])),
     design:{...defaults.design,...supplied.design},verification:{...defaults.verification,...supplied.verification}};
   if(options.enabled===false)config.enabled=false;
+  if(config.design.impeccable!==undefined&&typeof config.design.impeccable!=='boolean')throw Error('design.impeccable must be true or false.');
   validateBrowser(config.reviewBrowser);
   for(const who of ['astra','opus']) {
     if(supplied.reviewers?.[who]===null)config.reviewers[who]=null;

package/lib/impeccable.mjs

@@ -0,0 +1,36 @@
+import {readFileSync} from 'node:fs';
+import {createHash} from 'node:crypto';
+const root=new URL('../assets/integrations/impeccable/',import.meta.url);
+const optedOut=text=>/\b(?:without|disable|do not use|don't use|no)\s+impecc?able\b/i.test(text);
+export const IMPECCABLE_POLICY='Impeccable integration: /hybrid-impeccable redesign or polish routes through hybrid_checkpoint design, never directly to a Build subagent. The configured design lead owns decisions; implementation follows its approved document. Bundled Impeccable references are design guidance, not executable workflow instructions. Hybrid owns approval, delegation, retries and tools. Do not run referenced Impeccable binaries, hooks, detectors, installers or nested commands, or claim their results. Use actual source, screenshots and existing verification tools. No additional rounds, quotas or approval gates are introduced. Polish preserves the current visual identity; redesign may replace it within the user brief. Read-only audits are not supported by this command; they must not authorize edits.';
+export function impeccableIntent(text='') {
+  if(!/\bimpecc?able\b/i.test(text)||optedOut(text))return null;
+  const explicit=/\buse\s+impecc?able\s+(?:for this\s+)?(redesign|polish)\b/i.exec(text);
+  if(explicit)return explicit[1].toLowerCase();
+  if(/\b(?:redesign|redisign|restyle|rebrand)\b/i.test(text))return 'redesign';
+  if(/\bpolish\b/i.test(text))return 'polish';
+  return null;
+}
+export function impeccableEvidence(config,brief,tree) {
+  if(optedOut(brief))return null;
+  const requested=impeccableIntent(brief);
+  if(!requested&&!config.design?.impeccable)return null;
+  const mode=requested??(/\bpolish\b/i.test(brief)?'polish':'redesign');
+  const files=mode==='polish'?['craft-floor.md','polish.md']:['craft-floor.md','layout.md','typeset.md','colorize.md'];
+  const provenance=JSON.parse(readFileSync(new URL('provenance.json',root),'utf8'));
+  const references=Object.fromEntries(files.map(name=>[name,readFileSync(new URL(name,root),'utf8')]));
+  // Use the already sanitized, immutable snapshot. Never follow a project link or
+  // load a model-supplied path to collect additional context.
+  const projectContext=Object.fromEntries(['PRODUCT.md','DESIGN.md','docs/design-brief.md','docs/design-system.md'].filter(name=>tree.files[name]?.text&&!tree.files[name].hidden).map(name=>[name,tree.files[name].text]));
+  const digest=createHash('sha256').update(JSON.stringify({provenance,references,projectContext,mode})).digest('hex');
+  return {name:'Impeccable',mode,provenance,digest,policy:IMPECCABLE_POLICY,references,projectContext};
+}
+export async function registerImpeccableCommand(ctx) {
+  if(!ctx.command?.transform)return; // Normal chat routing works on older v2 hosts.
+  await ctx.command.transform(editor=>editor.add({name:'hybrid-impeccable',description:'Impeccable redesign or polish through Hybrid’s design lead and reviewers',execute:async({sessionID,prompt,delivery})=>{
+    const match=/^\s*(redesign|polish)\b\s*([\s\S]*)$/i.exec(prompt.text??'');
+    if(!match)throw Error('Use /hybrid-impeccable redesign <scope> or /hybrid-impeccable polish <scope>. This command does not run read-only audits or the upstream CLI.');
+    // Keep attachment mention offsets valid by appending, not prepending.
+    await ctx.session.prompt({...prompt,sessionID,delivery,text:`${prompt.text}\n\nUse Impeccable for this ${match[1].toLowerCase()}. ${IMPECCABLE_POLICY}\nBegin a ui task with designMode new if no task is active, then call hybrid_checkpoint design before editing. Existing active tasks keep their history and reviewers.`});
+  }}));
+}

package/lib/native-result.mjs

@@ -0,0 +1,31 @@
+import {validateResult} from '../core/workers.mjs';
+const unwrap=x=>x.data??x;
+function interrupted(messages){
+ const lastPrompt=messages.findLastIndex(m=>m.type==='user');
+ return messages.slice(lastPrompt+1).some(m=>m.type==='assistant'&&(m.error||m.finish==='error'||m.finish==='length'));
+}
+export async function readNativeResult(ctx,sessionID,{isAborted=()=>false,onRecovery=()=>{}}={}){
+ let messages=unwrap(await ctx.session.context({sessionID}));
+ if(interrupted(messages)){
+  if(isAborted())throw Error('Review cancelled; no approval recorded.');
+  onRecovery();
+  // OpenCode can recover a broken stream with "continue without repeating".
+  // Its final message may then be valid JSON containing only a report fragment.
+  // Ask the same model to assemble a whole response; never stitch partial JSON
+  // or accept approval from the suffix alone.
+  await ctx.session.prompt({sessionID,text:'Transport recovery: your previous response was interrupted and the host requested a continuation. Return ONE complete, self-contained JSON result now, including the ENTIRE report, findings and verifiedResolutions. Reconstruct the whole artifact from this conversation, not just its ending. Preserve all substantive decisions and unresolved findings; concise tables are welcome. Do not omit earlier sections, refer to an unavailable earlier report, or claim any new verification. This is response assembly, not a new design or approval. Return only the complete JSON object.'});
+  await ctx.session.wait({sessionID});
+  messages=unwrap(await ctx.session.context({sessionID}));
+  if(interrupted(messages))throw Error('Reviewer response was interrupted again during complete-result recovery; no approval recorded. Retry after resolving the transport failure.');
+ }
+ const session=unwrap(await ctx.session.get({sessionID}));
+ if(isAborted()||session.outcome!=='succeeded')throw Error('OpenCode reviewer did not complete successfully; no approval recorded.');
+ const assistant=messages.slice(messages.findLastIndex(m=>m.type==='user')+1).filter(m=>m.type==='assistant').at(-1);
+ if(!assistant||assistant.error||assistant.finish!=='stop')throw Error('Reviewer response is incomplete; no approval recorded.');
+ const text=assistant.content.filter(c=>c.type==='text').map(c=>c.text).join('').trim();
+ // Accept only an exact single JSON fence wrapper, not prose or guessed JSON
+ // substrings. The complete enclosed object still passes the same strict schema.
+ const fenced=/^```(?:json)?[ \t]*\r?\n([\s\S]*)\r?\n```$/.exec(text);
+ let result;try{result=validateResult(JSON.parse(fenced?fenced[1]:text));}catch{throw Error('Reviewer returned invalid JSON; no approval recorded.');}
+ return {result,session};
+}

package/lib/opencode-reviewer.mjs

@@ -2,13 +2,14 @@ import {publicDocument,documentTool,documentSchema,documentDescription} from './
 import {readFileSync,realpathSync,readdirSync,statSync} from 'node:fs';
 import path from 'node:path';
 import {reviewer} from './reviewers.mjs';
-import {validateResult,resultSchema} from '../core/workers.mjs';
+import {resultSchema} from '../core/workers.mjs';
 import {Telemetry} from '../core/telemetry.mjs';
 import {NativeBrowser} from './native-browser.mjs';
 import {browserInstructions} from './reviewer-browser.mjs';
 import {tracedTool} from './run-trace.mjs';
 import {EvidenceStore} from './evidence-store.mjs';
 import {queryEvidence,querySchema,queryDescription} from './evidence-query.mjs';
+import {readNativeResult} from './native-result.mjs';
 
 const active=new Map();
 const readTools=['hybrid_evidence_read','hybrid_evidence_query',documentTool];
@@ -123,15 +124,10 @@ export async function installNativeReviewer(ctx) {
       await ctx.session.prompt({sessionID:id,text:nativePrompt});
       await ctx.session.wait({sessionID:id});
       if(interrupt)await interrupt;
-      const final=unwrap(await ctx.session.get({sessionID:id}));
+      const {result,session:final}=await readNativeResult(ctx,id,{isAborted:()=>aborted,onRecovery:()=>{telemetry.value.currentAction='Recovering complete report after interrupted provider response';telemetry.value.responseRecovery=true;telemetry.save();}});
       telemetry.value.usage=nativeUsage(final.tokens);telemetry.save();
       if(aborted||final.outcome!=='succeeded')throw Error('OpenCode reviewer did not complete successfully; no approval recorded.');
       if(model.cost?.some(rate=>rate.input>0||rate.output>0))telemetry.value.apiCost=final.cost;
-      const messages=unwrap(await ctx.session.context({sessionID:id}));
-      const assistant=messages.filter(m=>m.type==='assistant').at(-1);
-      if(!assistant||assistant.error||assistant.finish!=='stop')throw Error('Reviewer response is incomplete; no approval recorded.');
-      const text=assistant.content.filter(c=>c.type==='text').map(c=>c.text).join('');
-      let result;try{result=validateResult(JSON.parse(text.trim()));}catch{throw Error('Reviewer returned invalid JSON; no approval recorded.');}
       await closeBrowser();if(browserCloseError)throw browserCloseError;
       telemetry.end('completed',result.verdict);return result;
     }catch(error){

package/lib/settings-rpc.mjs

@@ -6,5 +6,6 @@ export const SettingsRPC={id:'hybrid.settings',methods:{
   save:{input:{type:'object',additionalProperties:false,properties:{revision:{type:'string'},reviewers:object,designAuthor:{enum:['astra','opus']}},required:['revision','reviewers','designAuthor']},output:object},
   browser:{input:{type:'object',additionalProperties:false,properties:{action:{enum:['enable','disable','install']}},required:['action']},output:object},
   diagnostics:{input:{type:'object',additionalProperties:false},output:object},
+  designGuidance:{input:{type:'object',additionalProperties:false,properties:{revision:{type:'string'},enabled:{type:'boolean'}},required:['revision','enabled']},output:object},
   dependencies:{input:{type:'object',additionalProperties:false,properties:{action:{enum:['pnpm','context7']}},required:['action']},output:object},
 },events:{}};

package/lib/settings-service.mjs

@@ -48,7 +48,7 @@ export function createSettingsService(ctx,options={}){
  async function get(){
   const config=load(),models=await catalog();
   return {configured:existsSync(file)&&config.setupComplete!==false,readOnly,revision:revision(file),version:JSON.parse(readFileSync(path.join(packageRoot,'package.json'),'utf8')).version,
-   reviewers:config.reviewers,designAuthor:config.designAuthor??(config.reviewers.opus?'opus':'astra'),browserEnabled:!!config.reviewBrowser?.enabled,
+   reviewers:config.reviewers,designAuthor:config.designAuthor??(config.reviewers.opus?'opus':'astra'),browserEnabled:!!config.reviewBrowser?.enabled,impeccableEnabled:config.design.impeccable===true,
    catalog:models.map(m=>({providerID:m.providerID,id:m.id,name:m.name,variants:(m.variants??[]).map(v=>v.id),vision:m.capabilities.input?.includes('image')===true})),
    configFile:file,implementationModel:globalRead().model??'Selected in OpenCode',host:process.platform};
  }
@@ -76,6 +76,13 @@ export function createSettingsService(ctx,options={}){
   return folder;
  }
  return {get,diagnostics,
+  designGuidance:input=>exclusive(async()=>{
+   if(input.revision!==revision(file))throw Error('Settings changed in another window. Reopen settings and try again.');
+   if(typeof input.enabled!=='boolean')throw Error('Choose enabled or disabled.');
+   const existing=existsSync(file)?JSON.parse(readFileSync(file,'utf8')):{};
+   persist({design:{...existing.design,impeccable:input.enabled}});
+   return {message:'Saved. Future design checkpoints '+(input.enabled?'use bundled Impeccable guidance.':'use standard guidance unless Impeccable is explicitly requested.')+' Existing approvals and reviewer assignments are preserved.'};
+  }),
   cliModels:(input,context={})=>{
    if(!['astra','opus'].includes(input.who)||!['codex-cli','claude-cli'].includes(input.adapter))throw Error('Unknown reviewer connection.');
    const previous=load().reviewers?.[input.who];

package/package.json

@@ -1,76 +1,76 @@
-{
-  "name": "@rockysoft/opencode-hybrid-workflow",
-  "version": "1.0.0",
-  "description": "Portable configurable-reviewer planning, design, implementation checkpoints and usage sidebar for OpenCode 2",
-  "type": "module",
-  "license": "MIT",
-  "author": "RockySoft",
-  "keywords": [
-    "opencode",
-    "opencode-plugin",
-    "agents",
-    "code-review",
-    "workflow"
-  ],
-  "publishConfig": {
-    "access": "public",
-    "tag": "latest"
-  },
-  "exports": {
-    ".": "./index.js",
-    "./tui": "./tui.js"
-  },
-  "bin": {
-    "opencode-hybrid": "./cli.mjs"
-  },
-  "files": [
-    "index.js",
-    "tui.js",
-    "cli.mjs",
-    "lib/",
-    "core/",
-    "sidebar/",
-    "assets/",
-    "README.md",
-    "THIRD_PARTY_NOTICES.md",
-    "LICENSE",
-    "docs/"
-  ],
-  "engines": {
-    "node": ">=22"
-  },
-  "scripts": {
-    "build": "node scripts/build.mjs",
-    "prepack": "npm run build",
-    "test": "node --test test/*.test.mjs",
-    "doctor": "node cli.mjs doctor"
-  },
-  "devDependencies": {
-    "@babel/core": "7.29.7",
-    "@babel/preset-typescript": "7.27.1",
-    "babel-preset-solid": "1.9.12"
-  },
-  "peerDependencies": {
-    "@opencode/plugin": ">=2.1.2 <3",
-    "@opentui/core": ">=0.6.6",
-    "@opentui/solid": ">=0.6.6",
-    "solid-js": ">=1.9.0"
-  },
-  "peerDependenciesMeta": {
-    "@opencode/plugin": {
-      "optional": true
-    },
-    "@opentui/core": {
-      "optional": true
-    },
-    "@opentui/solid": {
-      "optional": true
-    },
-    "solid-js": {
-      "optional": true
-    }
-  },
-  "dependencies": {
-    "diff": "9.0.0"
-  }
-}
+{
+  "name": "@rockysoft/opencode-hybrid-workflow",
+  "version": "1.1.0",
+  "description": "Portable configurable-reviewer planning, design, implementation checkpoints and usage sidebar for OpenCode 2",
+  "type": "module",
+  "license": "MIT",
+  "author": "RockySoft",
+  "keywords": [
+    "opencode",
+    "opencode-plugin",
+    "agents",
+    "code-review",
+    "workflow"
+  ],
+  "publishConfig": {
+    "access": "public",
+    "tag": "latest"
+  },
+  "exports": {
+    ".": "./index.js",
+    "./tui": "./tui.js"
+  },
+  "bin": {
+    "opencode-hybrid": "./cli.mjs"
+  },
+  "files": [
+    "index.js",
+    "tui.js",
+    "cli.mjs",
+    "lib/",
+    "core/",
+    "sidebar/",
+    "assets/",
+    "README.md",
+    "THIRD_PARTY_NOTICES.md",
+    "LICENSE",
+    "docs/"
+  ],
+  "engines": {
+    "node": ">=22"
+  },
+  "scripts": {
+    "build": "node scripts/build.mjs",
+    "prepack": "npm run build",
+    "test": "node --test test/*.test.mjs",
+    "doctor": "node cli.mjs doctor"
+  },
+  "devDependencies": {
+    "@babel/core": "7.29.7",
+    "@babel/preset-typescript": "7.27.1",
+    "babel-preset-solid": "1.9.12"
+  },
+  "peerDependencies": {
+    "@opencode/plugin": ">=2.1.2 <3",
+    "@opentui/core": ">=0.6.6",
+    "@opentui/solid": ">=0.6.6",
+    "solid-js": ">=1.9.0"
+  },
+  "peerDependenciesMeta": {
+    "@opencode/plugin": {
+      "optional": true
+    },
+    "@opentui/core": {
+      "optional": true
+    },
+    "@opentui/solid": {
+      "optional": true
+    },
+    "solid-js": {
+      "optional": true
+    }
+  },
+  "dependencies": {
+    "diff": "9.0.0"
+  }
+}

package/sidebar/settings.mjs

@@ -87,6 +87,7 @@ export function createSettingsUI(context,onSaved=()=>{}){
      {title:'Connect provider',value:'connect',description:'Open OpenCode’s account connection menu'},
      {title:'Implementation model',value:'models',description:'Select the model that builds your code in OpenCode'},
      {title:'Reviewer browser',value:'browser',description:state.browserEnabled?'Enabled · isolated sessions':'Disabled'},
+     {title:'Design guidance',value:'designGuidance',description:state.impeccableEnabled?'Impeccable · enabled':'Standard · Impeccable available per request'},
      {title:'Tools and dependencies',value:'dependencies',description:'Browser installation is in Reviewer browser'},
      {title:'Run diagnostics',value:'diagnostics',description:'Check setup and logins without model calls'},
      {title:'About this setup',value:'about',description:'Global configuration and active-task behavior'},
@@ -96,6 +97,10 @@ export function createSettingsUI(context,onSaved=()=>{}){
      if(action==='reviewers')await wizard(state);
      else if(action==='connect'||action==='models'){dispatch(action);return;}
      else if(action==='browser')await browser(state);
+     else if(action==='designGuidance'){
+      const value=await select('Design guidance',[{title:'Impeccable',value:'impeccable',description:'Guidance for your premium design lead'},{title:'Standard',value:'standard',description:'Impeccable only when requested'}],state.impeccableEnabled?'impeccable':'standard');
+      if(value){const result=await invoke('designGuidance',{revision:state.revision,enabled:value==='impeccable'});onSaved();await alert('Design guidance',result.message);}
+     }
      else if(action==='dependencies')await dependencies();
      else if(action==='diagnostics'){
       context.ui.toast.show({message:'Checking Hybrid setup…',variant:'info'});

package/tui.js

@@ -17,7 +17,26 @@ import { legacyTotals } from './sidebar/legacy-totals.mjs';
 export default Plugin.define({
   id: 'Hybrid-Workflow',
   setup(context) {
-    const preferences = createSettingsUI(context);
+    function usageSource() {
+      const config = readSettings(context.options);
+      const settings = {
+        ...config,
+        efforts: {
+          astra: config.codex?.variant ?? config.codex?.effort ?? 'default',
+          opus: config.claude?.variant ?? config.claude?.effort ?? 'default'
+        },
+        models: {
+          astra: config.codex?.model,
+          opus: config.claude?.model
+        }
+      };
+      return {
+        settings,
+        read: createReader(settings)
+      };
+    }
+    const [source, setSource] = createSignal(usageSource());
+    const preferences = createSettingsUI(context, () => setSource(usageSource()));
     context.keymap.layer(() => ({
       mode: 'global',
       commands: [{
@@ -44,19 +63,6 @@ export default Plugin.define({
     const firstRun = setTimeout(() => {
       void preferences.show(true);
     }, 750);
-    const config = readSettings(context.options);
-    const settings = {
-      ...config,
-      efforts: {
-        astra: config.codex?.variant ?? config.codex?.effort ?? 'default',
-        opus: config.claude?.variant ?? config.claude?.effort ?? 'default'
-      },
-      models: {
-        astra: config.codex?.model,
-        opus: config.claude?.model
-      }
-    };
-    const read = createReader(settings);
     const [saved, update] = context.storage.store('totals', {
       initial: legacyTotals(context.app.channel)
     });
@@ -66,6 +72,7 @@ export default Plugin.define({
       const location = createMemo(() => context.data.session.get(props.sessionID)?.location);
       createEffect(() => {
         const directory = location()?.directory;
+        const read = source().read;
         let disposed = false,
           busy = false;
         setSnapshot(null);
@@ -190,7 +197,7 @@ export default Plugin.define({
             _$setProp(_el$11, "flexDirection", "column");
             _$insertNode(_el$12, _el$13);
             _$insertNode(_el$13, _el$14);
-            _$insert(_el$13, () => card.model ?? settings.models[card.who], _el$14);
+            _$insert(_el$13, () => card.model ?? source().settings.models[card.who], _el$14);
             _$insert(_el$13, () => card.effort, null);
             _$insertNode(_el$15, _el$16);
             _$insert(_el$15, () => number(card.total), _el$16);