@erclx/canon 4.98.0 → 4.99.0
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/README.md +1 -1
- package/claude/.claude-plugin/plugin.json +1 -1
- package/claude/skills/auto-ship/SKILL.md +6 -4
- package/claude/skills/draft-and-pick/REQUIREMENT.md +1 -1
- package/claude/skills/draft-and-pick/SKILL.md +1 -1
- package/claude/skills/draft-ready/SKILL.md +3 -3
- package/claude/skills/git-pr/SKILL.md +41 -21
- package/claude/skills/test-craft/REQUIREMENT.md +1 -1
- package/claude/skills/test-first/REQUIREMENT.md +1 -1
- package/claude/skills/ui-checklist/REQUIREMENT.md +49 -0
- package/claude/skills/ui-checklist/SKILL.md +71 -0
- package/claude/skills/ux-audit/REQUIREMENT.md +1 -1
- package/claude/skills/ux-measure/REQUIREMENT.md +1 -1
- package/docs/agents/demo.md +3 -1
- package/docs/agents/pr-evidence.md +34 -11
- package/docs/agents/pr-preview.md +4 -3
- package/docs/agents/tasks.md +3 -1
- package/docs/workflow/ai-workflow.md +4 -4
- package/docs/workflow/visual-design-workflow.md +2 -2
- package/package.json +1 -1
- package/src/claude/cases/workflow.ts +3 -2
- package/src/commands/demo.ts +4 -3
- package/src/commands/pr.ts +53 -1
- package/src/commands/tasks.ts +16 -0
- package/src/demo/compile.ts +20 -0
- package/src/demo/drive.ts +1 -0
- package/src/migrate/skill-names.ts +14 -6
- package/src/pr/evidence.ts +36 -1
- package/src/sandbox/expect.ts +2 -1
- package/src/tasks/archive.ts +115 -3
- package/standards/ready.md +2 -2
- package/standards/tasks.md +4 -2
- package/claude/skills/ui-test/REQUIREMENT.md +0 -48
- package/claude/skills/ui-test/SKILL.md +0 -87
|
@@ -1,87 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: ui-test
|
|
3
|
-
description: Routes each UI change to the test layer that can catch its break, writes end to end tests only for journeys and browser-only behavior, and produces a manual checklist for visual-only items. Use after implementing UI changes, or when asked "what should I test", "what do I verify", or "give me a test checklist". Do NOT use in empty sessions with no implementation context.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# UI test
|
|
7
|
-
|
|
8
|
-
## Guards
|
|
9
|
-
|
|
10
|
-
- If no implementation context exists in the session, stop: `❌ No implementation context. Describe what you built first.`
|
|
11
|
-
- Load `canon:test-craft` before writing any test, and report it rather than proceeding silently when it does not resolve.
|
|
12
|
-
|
|
13
|
-
## Analysis
|
|
14
|
-
|
|
15
|
-
Review the session to identify what was built or changed. Categorize each change, then route it:
|
|
16
|
-
|
|
17
|
-
- **Visual-only:** spacing, alignment, color, typography, layout proportions, animation timing. These become a manual checklist.
|
|
18
|
-
- **Journey or browser-only:** a flow across routes, a route change, or a behavior only a real browser renders, such as scroll, focus order across pages, or layout. These become end to end tests.
|
|
19
|
-
- **Everything else:** interactions, state transitions, form submissions, keyboard handling, conditional rendering, loading, empty, and error states. Route these through the `test-craft` layer table to a component test, or to a unit test when the logic renders nothing.
|
|
20
|
-
|
|
21
|
-
Never write an end to end test for a state a component test reaches. Exclude anything already covered by tests written during implementation.
|
|
22
|
-
|
|
23
|
-
## Component and unit tests
|
|
24
|
-
|
|
25
|
-
- Read the project's test config and an existing test at the layer first, and follow its runner, suffix, and placement.
|
|
26
|
-
- Read the `test-craft` component reference before the first component test.
|
|
27
|
-
- Assert each state through what a user sees or does, covering the happy path and the key edges.
|
|
28
|
-
- When the project has no component runner, write the checklist item for that state instead of an end to end test, and name the missing runner in the output. Do not fall back to end to end silently.
|
|
29
|
-
|
|
30
|
-
## E2e tests
|
|
31
|
-
|
|
32
|
-
Write Playwright tests for journeys and browser-only behavior only. Follow these rules:
|
|
33
|
-
|
|
34
|
-
- Read the `test-craft` end to end reference before the first one.
|
|
35
|
-
- Add tests to the project's existing `e2e/` layout and naming. If none exists, create `e2e/<feature>.spec.ts`.
|
|
36
|
-
- Use the project's existing Playwright config and test patterns. Read them first.
|
|
37
|
-
- Each test performs a user action across the journey and asserts the expected outcome.
|
|
38
|
-
- For Chrome extensions: load the unpacked extension via Playwright's `--load-extension` flag and use the extension's sidepanel or popup URL as the test target.
|
|
39
|
-
- Run every test written, at every layer. Fix failures before finishing.
|
|
40
|
-
|
|
41
|
-
Test structure:
|
|
42
|
-
|
|
43
|
-
```typescript
|
|
44
|
-
test('description of user flow', async ({ page }) => {
|
|
45
|
-
// Arrange: navigate, set up state
|
|
46
|
-
// Act: perform user action
|
|
47
|
-
// Assert: verify expected outcome
|
|
48
|
-
})
|
|
49
|
-
```
|
|
50
|
-
|
|
51
|
-
## Manual checklist
|
|
52
|
-
|
|
53
|
-
For visual-only items that cannot be asserted programmatically, and for any state left without a runner, produce a checklist. Group by feature area. Use `- [ ]` checkbox syntax.
|
|
54
|
-
|
|
55
|
-
```markdown
|
|
56
|
-
**What to verify visually:**
|
|
57
|
-
|
|
58
|
-
**<Feature area>**
|
|
59
|
-
|
|
60
|
-
- [ ] <action> → <expected visual result>
|
|
61
|
-
```
|
|
62
|
-
|
|
63
|
-
If every change is covered by a test, skip the manual checklist:
|
|
64
|
-
|
|
65
|
-
`✅ All changes covered by tests. No manual verification needed.`
|
|
66
|
-
|
|
67
|
-
### Persist the checklist
|
|
68
|
-
|
|
69
|
-
Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. Fall back to `latest` on an empty result.
|
|
70
|
-
|
|
71
|
-
When a manual checklist is produced, write it directly to `.canon/tmp/handoff/ui-checklist/<slug>.md` at the main worktree root, not the current worktree. Resolve that root the way `session-worktree` does. Create the directory if it does not exist. Always overwrite. This is a handoff file rather than a deliverable: `git-pr` posts it as a pull request comment once one opens, then removes it, and nothing here talks to `gh` directly.
|
|
72
|
-
|
|
73
|
-
From a linked worktree the file-editing tools refuse that path, so the checklist goes out through `Bash`. Send the `mkdir -p` and the heredoc as two plain commands rather than joining them with `&&`, which is refused as compound.
|
|
74
|
-
|
|
75
|
-
Skip the file write when every change is covered by tests and no checklist was produced.
|
|
76
|
-
|
|
77
|
-
The `.canon/tmp/` directory is gitignored. Do not stage or commit the file.
|
|
78
|
-
|
|
79
|
-
## Output order
|
|
80
|
-
|
|
81
|
-
1. Write and run the tests, naming each one's layer (report pass/fail)
|
|
82
|
-
2. Name any state left to the checklist for want of a component runner
|
|
83
|
-
3. If a manual checklist was produced, write it to file, then output only the file path in chat:
|
|
84
|
-
`📝 Wrote .canon/tmp/handoff/ui-checklist/<slug>.md`
|
|
85
|
-
4. If no checklist was needed: `✅ All changes covered by tests. No manual verification needed.`
|
|
86
|
-
|
|
87
|
-
Do not repeat the full checklist in chat.
|