peaks-cli 1.0.16 → 1.0.18
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/bin/peaks.js +0 -0
- package/dist/src/cli/commands/request-commands.js +109 -3
- package/dist/src/cli/commands/scan-commands.d.ts +3 -0
- package/dist/src/cli/commands/scan-commands.js +194 -0
- package/dist/src/cli/commands/workspace-commands.d.ts +3 -0
- package/dist/src/cli/commands/workspace-commands.js +32 -0
- package/dist/src/cli/program.js +4 -0
- package/dist/src/services/artifacts/artifact-lint-service.d.ts +23 -0
- package/dist/src/services/artifacts/artifact-lint-service.js +80 -0
- package/dist/src/services/artifacts/artifact-prerequisites.d.ts +28 -0
- package/dist/src/services/artifacts/artifact-prerequisites.js +77 -0
- package/dist/src/services/artifacts/repair-cycle-service.d.ts +23 -0
- package/dist/src/services/artifacts/repair-cycle-service.js +52 -0
- package/dist/src/services/artifacts/request-artifact-service.d.ts +14 -0
- package/dist/src/services/artifacts/request-artifact-service.js +73 -21
- package/dist/src/services/scan/acceptance-coverage-service.d.ts +42 -0
- package/dist/src/services/scan/acceptance-coverage-service.js +135 -0
- package/dist/src/services/scan/archetype-service.d.ts +5 -0
- package/dist/src/services/scan/archetype-service.js +253 -0
- package/dist/src/services/scan/diff-scope-service.d.ts +40 -0
- package/dist/src/services/scan/diff-scope-service.js +198 -0
- package/dist/src/services/scan/existing-system-service.d.ts +7 -0
- package/dist/src/services/scan/existing-system-service.js +300 -0
- package/dist/src/services/scan/scan-types.d.ts +59 -0
- package/dist/src/services/scan/scan-types.js +1 -0
- package/dist/src/services/scan/type-sanity-service.d.ts +23 -0
- package/dist/src/services/scan/type-sanity-service.js +108 -0
- package/dist/src/services/workspace/workspace-service.d.ts +16 -0
- package/dist/src/services/workspace/workspace-service.js +66 -0
- package/dist/src/shared/version.d.ts +1 -1
- package/dist/src/shared/version.js +1 -1
- package/package.json +1 -1
- package/skills/peaks-qa/SKILL.md +42 -0
- package/skills/peaks-rd/SKILL.md +65 -2
- package/skills/peaks-solo/SKILL.md +389 -263
- package/skills/peaks-solo/references/existing-system-extraction.md +78 -0
- package/skills/peaks-solo/results.tsv +0 -1
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
# Existing visual & convention system extraction
|
|
2
|
+
|
|
3
|
+
Run this step when `project-scan.md` archetype is `legacy-frontend`, `legacy-fullstack`, or `frontend-monorepo`. Skip for `greenfield` and `unknown`.
|
|
4
|
+
|
|
5
|
+
Output: `.peaks/<session-id>/system/existing-system.md`. The path lives under `system/` (not `ui/`) because the file records both UI tokens AND code conventions (service-layer signatures, hooks, naming) that backend-only or legacy-fullstack work consumes. UI design-draft and RD implementation MUST read this file and treat extracted tokens/conventions as hard constraints. New tokens or conventions may only be introduced when PRD explicitly authorizes them.
|
|
6
|
+
|
|
7
|
+
## Step 1 — Run the CLI (deterministic, source of truth)
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
peaks scan existing-system --project <repo> --json
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
The CLI emits stable JSON containing:
|
|
14
|
+
|
|
15
|
+
- `scanned`: `true | false` (skipped for greenfield / unknown archetypes; copy `scanSkippedReason` if false)
|
|
16
|
+
- `visualTokens`:
|
|
17
|
+
- `colors[]`, `spacing[]`, `typography[]`, `radii[]` — each entry is `{ name, value, source }` parsed deterministically from Less/Sass variables, CSS variables, and `tailwind.config.*` color blocks
|
|
18
|
+
- `sources[]` — every theme/style file the parser actually read (path + kind)
|
|
19
|
+
- `conventions`:
|
|
20
|
+
- `componentNaming`: `PascalCase | kebab-case | mixed | unknown` (decided from real file names under the component directory)
|
|
21
|
+
- `componentDir`, `serviceDir`, `hookDir` — first matching path found
|
|
22
|
+
- `samples[]` — up to 5 most-recently-modified files per kind
|
|
23
|
+
- `inconsistencies[]` — token names that have different values across sources
|
|
24
|
+
|
|
25
|
+
Copy these fields VERBATIM into `existing-system.md`. Do not re-classify tokens; do not invent additional samples.
|
|
26
|
+
|
|
27
|
+
## Step 2 — Render the markdown
|
|
28
|
+
|
|
29
|
+
Use the template below. Every value must come from the CLI JSON; leave a section as `- (none detected)` when the CLI returned an empty array.
|
|
30
|
+
|
|
31
|
+
```markdown
|
|
32
|
+
# Existing visual & convention system
|
|
33
|
+
**Project:** <name>
|
|
34
|
+
**Date:** YYYY-MM-DD
|
|
35
|
+
**CLI command:** peaks scan existing-system --project <repo> --json
|
|
36
|
+
**Source files inspected:** <paste visualTokens.sources[*].path>
|
|
37
|
+
|
|
38
|
+
## Color tokens
|
|
39
|
+
<paste visualTokens.colors as "- {name}: {value} (source: {source})">
|
|
40
|
+
|
|
41
|
+
## Typography
|
|
42
|
+
<paste visualTokens.typography>
|
|
43
|
+
|
|
44
|
+
## Spacing
|
|
45
|
+
<paste visualTokens.spacing>
|
|
46
|
+
|
|
47
|
+
## Radius
|
|
48
|
+
<paste visualTokens.radii>
|
|
49
|
+
|
|
50
|
+
## Component conventions
|
|
51
|
+
- Naming: <conventions.componentNaming>
|
|
52
|
+
- Directory: <conventions.componentDir>
|
|
53
|
+
- Sample files: <conventions.samples filtered by kind=component>
|
|
54
|
+
|
|
55
|
+
## Service layer convention
|
|
56
|
+
- Directory: <conventions.serviceDir>
|
|
57
|
+
- Sample files: <conventions.samples filtered by kind=service>
|
|
58
|
+
|
|
59
|
+
## Hooks convention
|
|
60
|
+
- Directory: <conventions.hookDir>
|
|
61
|
+
- Sample files: <conventions.samples filtered by kind=hook>
|
|
62
|
+
|
|
63
|
+
## Detected inconsistencies
|
|
64
|
+
<paste inconsistencies[*] verbatim; if empty, write "- (none)">
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
## Hard rules for downstream consumers
|
|
68
|
+
|
|
69
|
+
- **UI design-draft**: every color, font, radius, spacing value used in the draft MUST come from `visualTokens.*` above. New values require an explicit `## New tokens (requested)` section with PRD justification.
|
|
70
|
+
- **RD implementation**: new components must match `conventions.componentNaming` and live under `conventions.componentDir`. Service and hook code must match the recorded directory.
|
|
71
|
+
- **QA**: regression checks must verify that no new color/spacing values escaped the recorded token set; inconsistencies from the CLI become QA acceptance items (resolve or explicitly accept).
|
|
72
|
+
|
|
73
|
+
## When the CLI returns empty results
|
|
74
|
+
|
|
75
|
+
If `scanned=true` but all token arrays are empty AND `conventions.componentDir` is null, the project has no detectable token system or component convention. Record this verbatim in `existing-system.md` under `## Detected inconsistencies → no theme system; values are hard-coded across files; no canonical component dir`. Surface it in the TXT handoff as a known risk. Do NOT invent a token system.
|
|
76
|
+
|
|
77
|
+
When `scanned=false` (archetype = greenfield or unknown), do not write `existing-system.md` at all — the greenfield path applies.
|
|
78
|
+
|
|
@@ -1 +0,0 @@
|
|
|
1
|
-
timestamp commit skill old_score new_score status dimension note eval_mode
|