@smartsoft001/pro-claude-plugins 0.7.0 → 0.9.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@smartsoft001/pro-claude-plugins",
-  "version": "0.7.0",
+  "version": "0.9.0",
   "publishConfig": {
     "access": "public"
   },

package/plugins/flow/.claude-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "flow",
   "description": "Development flow skills for Linear-driven development workflow",
-  "version": "0.7.0"
+  "version": "0.9.0"
 }

package/plugins/flow/skills/impl/SKILL.md

@@ -63,6 +63,7 @@ Execute each step in order. Do not skip any step marked as MANDATORY.
 - [ ] **9. Verify implementation** — run tests, lint, build check
 - [ ] **9.5. E2E tests (conditional)** — if `E2E_TESTS_RECOMMENDED: YES`, delegate to `test-e2e` skill
 - [ ] **10. Capture "after" screenshots** — if `UI_CHANGE_REQUIRED: YES`, capture + post comparison to Linear + cleanup
+- [ ] **10.5. Mockup fidelity check (conditional)** — if `UI_CHANGE_REQUIRED: YES` and `docs/mockups/` exists, compare the changed page against its mockup export and fix divergences (max 2 fix-and-recheck iterations) before the screenshot verification checkpoint (11); after any fix, re-run tests/lint/build on the touched projects
 - [ ] **11. MANDATORY: Screenshot verification** — output `SCREENSHOT_REQUIREMENT_MET: YES/NO`, block if missing
 - [ ] **12. Create completion comment** — delegate to `shared-impl-reporter`, post to Linear
 - [ ] **13. MANDATORY: Write reports in Polish** — all Linear comments must be in Polish language
@@ -260,6 +261,7 @@ Continue to Step 3.
    - Verify (lint, tests, build)
    - E2E tests (if UI)
    - Screenshots (if UI) — before + after + post to Linear
+   - Mockup fidelity check (if UI and docs/mockups/ exists) — compare against the export, max 2 fix-and-recheck iterations, re-run tests/lint/build after fixes
    - Create completion comment (shared-impl-reporter) — IN POLISH
    - Update status
 
@@ -623,6 +625,78 @@ The agent will:
 - After screenshots: ✅ COMPLETED & POSTED TO LINEAR
 ```
 
+Continue to Step 3e-mockup.
+
+#### Step 3e-mockup: Visual Fidelity Check Against Approved Mockups (CONDITIONAL)
+
+**⚠️ CONDITIONAL: Execute this step ONLY IF `UI_CHANGE_REQUIRED: YES` AND the workspace contains a `docs/mockups/` directory.** Otherwise skip to Step 3f-verify.
+
+Screenshots exist to be COMPARED, not only archived. A page can pass tests,
+lint and build while rendering the wrong component variant, a broken footer or
+raw translation keys — divergences that stay invisible until the screenshot is
+put NEXT TO the approved design. This step closes that loop while the context
+is still loaded, instead of leaving it to post-hoc review.
+
+**Process:**
+
+1. **Find the reference.** Match the page(s) from the Screenshot Plan to their
+   exports in `docs/mockups/` by file name (read the directory's README for
+   the route → file map; `-mobile` / `-kontrast` suffixes are viewport/contrast
+   variants). Some references are component-level exports (a single card, list
+   item or searchbar) — for those, compare that component within the page, not
+   the whole page. If the changed component is reused across pages, compare ONE
+   representative page. No matching export → record `Mockup check: N/A` in the
+   Screenshot Plan and skip to Step 3f-verify.
+2. **Capture local screenshots via the `screenshot-reporter` agent** in
+   capture-only mode (the skill's own tool list has no browser access — the
+   agent does). Do NOT rely on the uploaded "after" screenshots — they may
+   already be cleaned up.
+
+   ```
+   Capture FULL-PAGE screenshots (mockup exports are full-page frames —
+   a viewport-only shot would fake missing-section divergences):
+   - Page(s): [pages matched in item 1]
+   - Viewports: desktop (1920x1080); mobile (375x667) ONLY IF a -mobile
+     export exists for the page
+   - Phase: mockup-check — capture only: return local file paths,
+     do NOT upload, do NOT post to Linear, do NOT clean up
+   ```
+
+   `-kontrast` exports are out of scope for this loop unless the subtask
+   changed contrast/dark-mode styling — the high-contrast mode is owned by
+   the shared WCAG widget and dedicated a11y checks.
+3. **Read both images side by side** and list every divergence in: section
+   layout, component structure (thumbnail / metadata / action-button
+   arrangement), brand palette and tokens, typography, ornaments and
+   decorative assets, raw translation keys visible on screen.
+4. **Judge structure over theme, and scope to THIS subtask.** Component
+   exports may come from a shared, multi-project design system: the project's
+   own palette and typography win over the sample's theme. Ignore content
+   differences (mockups carry lorem-ipsum text and placeholder photos),
+   data-dependent counts, and sub-pixel rendering noise. A view-state mismatch
+   (grid vs list) counts only when the mockup depicts the same view state —
+   check the README's notes. A divergence caused by a page or module that a
+   DIFFERENT subtask owns (e.g. a section not implemented yet) is out of
+   scope: note it for the completion comment, do not fix it here.
+5. **Fix real divergences NOW**, re-capture, re-compare. **Hard bound: at most
+   2 fix-and-recheck iterations.** Whatever still diverges after the second
+   pass goes into the completion comment as an explicit list — do not keep
+   looping; structural and brand fidelity is the bar, pixel-perfection is not.
+   Fixes are code changes: after the loop, re-run the Step 3e verification
+   (tests / lint / build, scoped to the touched projects) — fixed code must
+   not reach "In Review" on stale results (Guideline: run tests before
+   marking complete). If any fix was applied, re-launch `screenshot-reporter`
+   for a final "after" capture and post an updated comparison to Linear — the
+   one posted in Step 3e-visual-after no longer shows the shipped state.
+
+**Update Screenshot Plan status:**
+
+```markdown
+### Screenshot Plan
+
+- Mockup check: [✅ MATCHES / ⚠️ divergences listed in completion comment / N/A (no matching export)]
+```
+
 #### Step 3f-verify: MANDATORY Screenshot Verification Checkpoint
 
 **⚠️ THIS VERIFICATION CANNOT BE SKIPPED**
@@ -641,6 +715,7 @@ Before creating the completion comment, verify the screenshot requirement:
 - [ ] Before screenshots captured: [YES with Task ID / NO - BLOCKER]
 - [ ] After screenshots captured: [YES / NO - BLOCKER]
 - [ ] Screenshots posted to Linear: [YES / NO - BLOCKER]
+- [ ] Mockup check (only if `docs/mockups/` exists): [MATCHES / divergences listed / N/A]
 
 **If UI_CHANGE_REQUIRED: NO:**
 
@@ -673,6 +748,7 @@ Files Modified: [list with descriptions]
 Files Created: [list with purposes]
 Test Results: [unit/e2e status]
 Translations: [changed keys if any]
+Mockup Check: [MATCHES / remaining divergences as an explicit list / N/A — from Step 3e-mockup]
 Notes: [additional notes]
 Blocker Info: [if blocked]
 ```
@@ -915,7 +991,7 @@ When verification fails, delegate to appropriate fix agent:
 19. **Capture before screenshots in background**: Launch `screenshot-reporter` agent with `run_in_background: true` BEFORE implementing UI changes to capture "before" state while implementation proceeds
 20. **Capture after screenshots + post to Linear**: After implementation, launch `screenshot-reporter` agent to capture "after" screenshots, generate comparison report, post to Linear, and cleanup
 21. **Document translations changes**: If `apps/web/public/translations.json` was modified, include a table with added/changed translation keys and their PL/EN values in the Implementation Report
-21a. **⚠️ MANDATORY: Translation completeness before completion**: No hardcoded UI strings — every static label, heading, button, aria-label, meta/SEO text goes through a translation key. Before marking a subtask complete, verify that EVERY key referenced in the changed templates/TS exists in `apps/web/public/translations.json` in BOTH `pl` and `en` (a raw `GROUP.key` rendered in the UI is a defect), and that the touched groups are complete against the design/mockup — every visible text on the mockup has its key. When a reference project is available, diff the touched groups against it and fill the gaps
+21a. **⚠️ MANDATORY: Translation completeness before completion**: No hardcoded UI strings — every static label, heading, button, aria-label, meta/SEO text goes through a translation key. Before marking a subtask complete, RUN the repo's translation check rather than eyeballing it — reading a diff does not prove a key resolves, and a raw `GROUP.key` rendered in the UI is one of the most visible defects a user can hit. Use `npm run check:translations` when the project defines it (museum projects wire it to `mobilems-check-translations`), otherwise fall back to whatever check the repo provides. Fix everything it reports: keys referenced in code but undefined, `pl`/`en` parity gaps, and — when a reference project is configured — groups that are incomplete against it. Only then mark the subtask done
 22. **Capture screenshots in both modes**: Agent captures screenshots in BOTH normal mode and dark mode (high contrast) for complete visual documentation
 23. **Ask before collecting feedback for agent evolution**: When user provides corrections or suggestions during implementation, **explicitly ask** if they want to create a Linear issue for the improvement. Only user-confirmed feedback (answered "Yes") should be processed at evolution checkpoints (Step 3g-evolve, Step 4a) via `shared-agent-evolver` agent.
 24. **Never modify agent files directly during implementation**: The `shared-agent-evolver` agent files all proposals as Linear issues for manual review — it does NOT modify agent, command, or skill files directly.

package/plugins/flow-external/.claude-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "flow-external",
   "description": "Development flow skills for standalone Angular 6-11 projects without framework (Angular CLI, Karma/Jasmine, Bootstrap 4)",
-  "version": "0.7.0"
+  "version": "0.9.0"
 }

package/plugins/flow-legacy/.claude-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "flow-legacy",
   "description": "Development flow skills for legacy Angular 14 projects with Linear-driven workflow",
-  "version": "0.7.0"
+  "version": "0.9.0"
 }

package/plugins/smart-pro/.claude-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "smart-pro",
   "description": "Smart-pro integration - safety validation, audit logging, and auto-formatting hooks",
-  "version": "0.7.0"
+  "version": "0.9.0"
 }