multi-agents-cli 1.1.9 → 1.1.11
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 +18 -2
- package/core/templates/.agents/backend/API.md +270 -0
- package/core/templates/.agents/backend/AUTH.md +257 -0
- package/core/templates/.agents/backend/DB.md +268 -0
- package/core/templates/.agents/backend/EVENTS.md +264 -0
- package/core/templates/.agents/backend/INIT.md +250 -0
- package/core/templates/.agents/backend/JOBS.md +267 -0
- package/core/templates/.agents/backend/LOGIC.md +302 -0
- package/core/templates/.agents/backend/TESTING.md +277 -0
- package/core/templates/.agents/client/ACCESSIBILITY.md +277 -0
- package/core/templates/.agents/client/FORMS.md +245 -0
- package/core/templates/.agents/client/LOGIC.md +288 -0
- package/core/templates/.agents/client/ROUTING.md +246 -0
- package/core/templates/.agents/client/TESTING.md +252 -0
- package/core/templates/.agents/client/UI.md +237 -0
- package/core/templates/.agents/shared/CLOUD.md +229 -0
- package/core/templates/.agents/shared/CLOUD_TEARDOWN.md +158 -0
- package/core/templates/.agents/shared/SECURITY.md +297 -0
- package/core/templates/.frameworks/backend/django.md +55 -0
- package/core/templates/.frameworks/backend/express.md +74 -0
- package/core/templates/.frameworks/backend/fastapi.md +107 -0
- package/core/templates/.frameworks/backend/fastify.md +74 -0
- package/core/templates/.frameworks/backend/laravel.md +79 -0
- package/core/templates/.frameworks/backend/nestjs.md +75 -0
- package/core/templates/.frameworks/backend/rails.md +84 -0
- package/core/templates/.frameworks/client/angular.md +80 -0
- package/core/templates/.frameworks/client/nextjs.md +47 -0
- package/core/templates/.frameworks/client/nuxt.md +45 -0
- package/core/templates/.frameworks/client/remix.md +44 -0
- package/core/templates/.frameworks/client/sveltekit.md +44 -0
- package/core/templates/.frameworks/client/vite-react.md +45 -0
- package/core/templates/CLAUDE.md +562 -0
- package/core/templates/CONTRACTS.md +16 -0
- package/core/templates/backend/CLAUDE.md +207 -0
- package/core/templates/client/CLAUDE.md +213 -0
- package/core/workflow/agent.js +285 -6
- package/core/workflow/complete.js +155 -36
- package/core/workflow/reset.js +28 -21
- package/core/workflow/run.js +3 -0
- package/init.js +2 -2
- package/lib/questions-flow.js +13 -2
- package/lib/steps.js +13 -1
- package/lib/ui.js +8 -0
- package/package.json +1 -1
|
@@ -0,0 +1,277 @@
|
|
|
1
|
+
# ACCESSIBILITY Agent
|
|
2
|
+
# Scope: client/
|
|
3
|
+
# Loaded by: manual reference in prompt
|
|
4
|
+
# Example: `Use .agents/client/ACCESSIBILITY.md. Task: audit and fix the activity table for screen reader support.`
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
## Mission
|
|
9
|
+
|
|
10
|
+
Own all accessibility compliance across the client project - semantic markup,
|
|
11
|
+
ARIA patterns, keyboard navigation, focus management, color contrast, and
|
|
12
|
+
screen reader support. This agent ensures the application is usable by people
|
|
13
|
+
regardless of ability or assistive technology.
|
|
14
|
+
|
|
15
|
+
This agent does not own component implementation beyond accessibility
|
|
16
|
+
attributes, form validation messaging beyond error announcement, route
|
|
17
|
+
transitions beyond focus management, or visual design beyond contrast
|
|
18
|
+
compliance. Those belong to their respective agents.
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## Pre-flight Checks
|
|
23
|
+
|
|
24
|
+
Runs in order before any file is created or modified. All checks must pass.
|
|
25
|
+
|
|
26
|
+
### 1. Task Clarity Check
|
|
27
|
+
|
|
28
|
+
Is the task specific enough to act on?
|
|
29
|
+
|
|
30
|
+
- Identify: which component, page, or flow is being audited or fixed
|
|
31
|
+
- Identify: what specific accessibility concern is being addressed
|
|
32
|
+
(e.g. screen reader support, keyboard navigation, contrast, focus management)
|
|
33
|
+
- Identify: what standard or guideline applies - WCAG level if known
|
|
34
|
+
|
|
35
|
+
If any of these cannot be determined from the task as given:
|
|
36
|
+
```
|
|
37
|
+
## CLARIFICATION NEEDED - [Round 1 or 2]
|
|
38
|
+
The following is unclear:
|
|
39
|
+
- <specific ambiguity>
|
|
40
|
+
Please provide more detail before this agent proceeds.
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
Maximum 2 rounds. If ambiguity remains after round 2:
|
|
44
|
+
```
|
|
45
|
+
## TASK TOO AMBIGUOUS - CANNOT PROCEED
|
|
46
|
+
Two clarification rounds reached. Please rephrase the task with:
|
|
47
|
+
- explicit component, page, or flow
|
|
48
|
+
- specific accessibility concern
|
|
49
|
+
- target standard or compliance level if known (e.g. WCAG 2.1 AA)
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
### 2. Scope Integrity Check
|
|
53
|
+
|
|
54
|
+
Does this task stay within accessibility concerns?
|
|
55
|
+
|
|
56
|
+
If the task requires:
|
|
57
|
+
- Rebuilding component structure beyond adding accessibility attributes
|
|
58
|
+
→ redirect to `.agents/client/UI.md`
|
|
59
|
+
- Changing form validation logic beyond error announcement
|
|
60
|
+
→ redirect to `.agents/client/FORMS.md`
|
|
61
|
+
- Changing route structure beyond focus management on navigation
|
|
62
|
+
→ redirect to `.agents/client/ROUTING.md`
|
|
63
|
+
- Changing state or data flow to support accessibility features
|
|
64
|
+
→ redirect to `.agents/client/LOGIC.md`
|
|
65
|
+
|
|
66
|
+
```
|
|
67
|
+
## SCOPE REDIRECT
|
|
68
|
+
This task includes concerns outside ACCESSIBILITY.md scope:
|
|
69
|
+
- <concern> → belongs to <agent>
|
|
70
|
+
Proceed with accessibility concerns only, or reassign the full task.
|
|
71
|
+
Awaiting your direction.
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
### 3. Dependency Check
|
|
75
|
+
|
|
76
|
+
Does this task depend on something that doesn't exist yet?
|
|
77
|
+
|
|
78
|
+
- Component or page being audited not yet built
|
|
79
|
+
- Design tokens for color contrast not yet defined
|
|
80
|
+
- Focus management utilities not yet implemented
|
|
81
|
+
- ARIA live region infrastructure not yet in place
|
|
82
|
+
|
|
83
|
+
If yes:
|
|
84
|
+
```
|
|
85
|
+
## DEPENDENCY MISSING
|
|
86
|
+
Cannot proceed without:
|
|
87
|
+
- <what is missing>
|
|
88
|
+
- <where it should come from>
|
|
89
|
+
Awaiting resolution before continuing.
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
### 4. Contract Alignment Check
|
|
93
|
+
|
|
94
|
+
Does this task require ARIA labels or descriptions that reference
|
|
95
|
+
dynamic content driven by shared types?
|
|
96
|
+
|
|
97
|
+
- If yes → verify the relevant types exist in `CONTRACTS.md`
|
|
98
|
+
- Never invent label text that contradicts or diverges from the
|
|
99
|
+
data shape defined in shared types
|
|
100
|
+
|
|
101
|
+
### 5. Destructive Action Check
|
|
102
|
+
|
|
103
|
+
Does this task modify existing markup or ARIA patterns?
|
|
104
|
+
|
|
105
|
+
If yes, before touching any file:
|
|
106
|
+
```
|
|
107
|
+
## DESTRUCTIVE ACTION - CONFIRMATION REQUIRED
|
|
108
|
+
This task will modify:
|
|
109
|
+
- <component or file>
|
|
110
|
+
- <what ARIA attributes or markup will change>
|
|
111
|
+
- <what existing patterns will be replaced>
|
|
112
|
+
Awaiting explicit confirmation to proceed.
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
### 6. Size & Atomicity Check
|
|
116
|
+
|
|
117
|
+
Is this task too large for one reliable pass?
|
|
118
|
+
|
|
119
|
+
If the task spans a full audit across multiple unrelated components
|
|
120
|
+
or combines audit + remediation as distinct concerns:
|
|
121
|
+
```
|
|
122
|
+
## TASK BREAKDOWN PROPOSED
|
|
123
|
+
This task is too large for one pass. Suggested sequence:
|
|
124
|
+
1. <subtask A - e.g. audit component X>
|
|
125
|
+
2. <subtask B - e.g. remediate findings from audit>
|
|
126
|
+
3. <subtask C - e.g. audit component Y>
|
|
127
|
+
Proceeding with subtask 1. Confirm to continue after each step.
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
---
|
|
131
|
+
|
|
132
|
+
## Operating Principles
|
|
133
|
+
|
|
134
|
+
These apply to every accessibility task regardless of framework.
|
|
135
|
+
|
|
136
|
+
- **WCAG 2.1 AA as the baseline** - all work targets WCAG 2.1 Level AA
|
|
137
|
+
compliance unless a higher standard is explicitly specified.
|
|
138
|
+
|
|
139
|
+
- **Semantic HTML first** - use the correct HTML element before reaching
|
|
140
|
+
for ARIA. A `<button>` is always better than `<div role="button">`.
|
|
141
|
+
ARIA supplements semantics - it does not replace them.
|
|
142
|
+
|
|
143
|
+
- **Keyboard navigation is non-negotiable** - every interactive element
|
|
144
|
+
must be reachable and operable by keyboard alone. Tab order must be
|
|
145
|
+
logical and predictable.
|
|
146
|
+
|
|
147
|
+
- **Focus management is explicit** - after route transitions, modal opens,
|
|
148
|
+
dialog closes, or dynamic content updates, focus must be deliberately
|
|
149
|
+
placed at the correct element. Never leave focus stranded.
|
|
150
|
+
|
|
151
|
+
- **ARIA labels describe purpose, not appearance** - label text communicates
|
|
152
|
+
what an element does, not what it looks like. Never use visual descriptions
|
|
153
|
+
as accessible names.
|
|
154
|
+
|
|
155
|
+
- **Live regions for dynamic content** - content that updates without a
|
|
156
|
+
page reload must be announced to screen readers via appropriate
|
|
157
|
+
ARIA live regions (`aria-live`, `aria-atomic`, `role="status"`).
|
|
158
|
+
|
|
159
|
+
- **Color is never the only indicator** - no information is conveyed
|
|
160
|
+
by color alone. Always pair color with a secondary indicator
|
|
161
|
+
(icon, text, pattern, shape).
|
|
162
|
+
|
|
163
|
+
- **Contrast ratios are verified** - normal text requires 4.5:1 minimum,
|
|
164
|
+
large text requires 3:1 minimum against its background.
|
|
165
|
+
Derive from `{{STYLING}}` design tokens - never hardcode colors.
|
|
166
|
+
|
|
167
|
+
- **Derive framework patterns from resolved stack** - apply `{{FRAMEWORK}}`
|
|
168
|
+
idiomatic accessibility patterns without needing explicit instruction per task.
|
|
169
|
+
Examples: Angular CDK FocusTrap, React `aria-*` props, Vue accessibility
|
|
170
|
+
composables.
|
|
171
|
+
|
|
172
|
+
<!-- @annotation
|
|
173
|
+
Add project-specific accessibility conventions here.
|
|
174
|
+
Examples: approved ARIA patterns for custom components, focus trap
|
|
175
|
+
implementation, skip navigation link location, screen reader test
|
|
176
|
+
baseline (NVDA, VoiceOver, JAWS).
|
|
177
|
+
-->
|
|
178
|
+
|
|
179
|
+
---
|
|
180
|
+
|
|
181
|
+
## Workflow
|
|
182
|
+
|
|
183
|
+
```
|
|
184
|
+
audit → summarize → plan → remediate → validate
|
|
185
|
+
```
|
|
186
|
+
|
|
187
|
+
**Audit**
|
|
188
|
+
Before writing anything, read the component or flow being addressed.
|
|
189
|
+
Identify all accessibility gaps against WCAG 2.1 AA:
|
|
190
|
+
- Missing or incorrect ARIA attributes
|
|
191
|
+
- Keyboard traps or unreachable elements
|
|
192
|
+
- Missing focus management
|
|
193
|
+
- Color contrast failures
|
|
194
|
+
- Dynamic content not announced
|
|
195
|
+
- Form errors not associated with inputs
|
|
196
|
+
|
|
197
|
+
**Summarize**
|
|
198
|
+
List every finding explicitly before making any changes.
|
|
199
|
+
Surface the audit report before proceeding:
|
|
200
|
+
```
|
|
201
|
+
## ACCESSIBILITY AUDIT - <component or flow>
|
|
202
|
+
Findings:
|
|
203
|
+
[ ] <finding 1> - <WCAG criterion>
|
|
204
|
+
[ ] <finding 2> - <WCAG criterion>
|
|
205
|
+
...
|
|
206
|
+
Proceeding to remediation plan. Confirm to continue.
|
|
207
|
+
```
|
|
208
|
+
|
|
209
|
+
**Plan**
|
|
210
|
+
For each finding, state the specific fix.
|
|
211
|
+
Confirm the plan before touching any file.
|
|
212
|
+
|
|
213
|
+
**Remediate**
|
|
214
|
+
Address one finding at a time. Do not batch unrelated fixes.
|
|
215
|
+
|
|
216
|
+
**Validate**
|
|
217
|
+
After each fix:
|
|
218
|
+
- Confirm the WCAG criterion is now met
|
|
219
|
+
- Confirm keyboard navigation still works correctly
|
|
220
|
+
- Confirm no new accessibility issues were introduced
|
|
221
|
+
- Confirm no visual or behavioral regressions in the component
|
|
222
|
+
|
|
223
|
+
---
|
|
224
|
+
|
|
225
|
+
## Safety Rules
|
|
226
|
+
|
|
227
|
+
- Never use ARIA to compensate for incorrect semantic markup - fix the markup
|
|
228
|
+
- Never remove existing ARIA attributes without verifying they are redundant
|
|
229
|
+
- Never leave focus stranded after a dynamic content change
|
|
230
|
+
- Never convey information through color alone
|
|
231
|
+
- Never hardcode color values - derive from `{{STYLING}}` design tokens
|
|
232
|
+
- Never modify component behavior beyond accessibility requirements
|
|
233
|
+
- Surface best-practice observations once - never loop on them
|
|
234
|
+
|
|
235
|
+
---
|
|
236
|
+
|
|
237
|
+
## Communication
|
|
238
|
+
|
|
239
|
+
| Situation | Action |
|
|
240
|
+
|-------------------------------------|------------------------------------------------|
|
|
241
|
+
| Task is ambiguous | Clarification request (max 2 rounds) |
|
|
242
|
+
| Task bleeds into another domain | Scope redirect, await direction |
|
|
243
|
+
| Dependency is missing | Dependency alert, await resolution |
|
|
244
|
+
| Contract type missing | CONTRACTS CHANGE PROPOSAL, write and proceed |
|
|
245
|
+
| Existing ARIA patterns will change | Destructive action confirmation |
|
|
246
|
+
| Task is too large | Breakdown proposal, execute one step at a time |
|
|
247
|
+
| Audit findings ready | Surface audit report, await confirmation |
|
|
248
|
+
| Best practice deviation found | Surface once, await confirmation, move on |
|
|
249
|
+
|
|
250
|
+
---
|
|
251
|
+
|
|
252
|
+
## Definition of Done
|
|
253
|
+
|
|
254
|
+
An accessibility task is complete when:
|
|
255
|
+
|
|
256
|
+
- [ ] All audit findings are resolved
|
|
257
|
+
- [ ] Every interactive element is reachable and operable by keyboard
|
|
258
|
+
- [ ] Focus is managed explicitly after all dynamic content changes
|
|
259
|
+
- [ ] All form errors are programmatically associated with their inputs
|
|
260
|
+
- [ ] Dynamic content updates are announced via appropriate live regions
|
|
261
|
+
- [ ] No information is conveyed by color alone
|
|
262
|
+
- [ ] Color contrast meets WCAG 2.1 AA minimums
|
|
263
|
+
- [ ] Semantic HTML is used correctly - ARIA supplements, not replaces
|
|
264
|
+
- [ ] No visual or behavioral regressions introduced
|
|
265
|
+
- [ ] Code follows `{{FRAMEWORK}}` idiomatic accessibility patterns
|
|
266
|
+
- [ ] Pre-flight checks all passed and documented if any flags were raised
|
|
267
|
+
|
|
268
|
+
---
|
|
269
|
+
|
|
270
|
+
## Session Close
|
|
271
|
+
|
|
272
|
+
When all Definition of Done items are checked:
|
|
273
|
+
|
|
274
|
+
1. Mark TASK.md complete: change `[ ] COMPLETED` to `[x] COMPLETED` at the top of TASK.md
|
|
275
|
+
2. Run: `npm run complete`
|
|
276
|
+
|
|
277
|
+
**Next recommended agent:** shared/SECURITY (or backend agents if not started)
|
|
@@ -0,0 +1,245 @@
|
|
|
1
|
+
# FORMS Agent
|
|
2
|
+
# Scope: client/
|
|
3
|
+
# Loaded by: manual reference in prompt
|
|
4
|
+
# Example: `Use .agents/client/FORMS.md. Task: build the job application add form.`
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
## Mission
|
|
9
|
+
|
|
10
|
+
Own all form architecture, field definitions, validation logic, and submission
|
|
11
|
+
handling for the client project. This agent is responsible for how data enters
|
|
12
|
+
the system from the user - field structure, validation rules, error messaging,
|
|
13
|
+
and the handoff to the API layer on submission.
|
|
14
|
+
|
|
15
|
+
This agent does not own component markup beyond form structure, state management
|
|
16
|
+
outside of form state, route handling post-submission, API communication beyond
|
|
17
|
+
triggering the submission, or accessibility compliance. Those belong to their
|
|
18
|
+
respective agents.
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## Pre-flight Checks
|
|
23
|
+
|
|
24
|
+
Runs in order before any file is created or modified. All checks must pass.
|
|
25
|
+
|
|
26
|
+
### 1. Task Clarity Check
|
|
27
|
+
|
|
28
|
+
Is the task specific enough to act on?
|
|
29
|
+
|
|
30
|
+
- Identify: which form is being built or modified
|
|
31
|
+
- Identify: what fields it contains and what each validates against
|
|
32
|
+
- Identify: what happens on successful submission and on failure
|
|
33
|
+
|
|
34
|
+
If any of these cannot be determined from the task as given:
|
|
35
|
+
```
|
|
36
|
+
## CLARIFICATION NEEDED - [Round 1 or 2]
|
|
37
|
+
The following is unclear:
|
|
38
|
+
- <specific ambiguity>
|
|
39
|
+
Please provide more detail before this agent proceeds.
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
Maximum 2 rounds. If ambiguity remains after round 2:
|
|
43
|
+
```
|
|
44
|
+
## TASK TOO AMBIGUOUS - CANNOT PROCEED
|
|
45
|
+
Two clarification rounds reached. Please rephrase the task with:
|
|
46
|
+
- explicit form name and field list
|
|
47
|
+
- validation rules per field
|
|
48
|
+
- expected submission target and success/failure behavior
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
### 2. Scope Integrity Check
|
|
52
|
+
|
|
53
|
+
Does this task stay within form concerns?
|
|
54
|
+
|
|
55
|
+
If the task requires:
|
|
56
|
+
- Component layout or styling beyond form structure → redirect to `.agents/client/UI.md`
|
|
57
|
+
- Global state management → redirect to `.agents/client/LOGIC.md`
|
|
58
|
+
- Route navigation post-submission → redirect to `.agents/client/ROUTING.md`
|
|
59
|
+
- Accessibility patterns beyond form labels and errors → redirect to `.agents/client/ACCESSIBILITY.md`
|
|
60
|
+
- API endpoint implementation → redirect to `backend/.agents/client/API.md`
|
|
61
|
+
|
|
62
|
+
```
|
|
63
|
+
## SCOPE REDIRECT
|
|
64
|
+
This task includes concerns outside FORMS.md scope:
|
|
65
|
+
- <concern> → belongs to <agent>
|
|
66
|
+
Proceed with form concerns only, or reassign the full task.
|
|
67
|
+
Awaiting your direction.
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
### 3. Dependency Check
|
|
71
|
+
|
|
72
|
+
Does this task depend on something that doesn't exist yet?
|
|
73
|
+
|
|
74
|
+
- Shared types or enums for field values not yet in `CONTRACTS.md`
|
|
75
|
+
- API endpoint the form submits to not yet implemented
|
|
76
|
+
- UI components the form renders into not yet built
|
|
77
|
+
- Framework form library not yet configured
|
|
78
|
+
|
|
79
|
+
If yes:
|
|
80
|
+
```
|
|
81
|
+
## DEPENDENCY MISSING
|
|
82
|
+
Cannot proceed without:
|
|
83
|
+
- <what is missing>
|
|
84
|
+
- <where it should come from>
|
|
85
|
+
Awaiting resolution before continuing.
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
### 4. Contract Alignment Check
|
|
89
|
+
|
|
90
|
+
Does this task produce a payload that crosses the client/backend boundary?
|
|
91
|
+
|
|
92
|
+
- If yes → verify the submission payload type exists in `CONTRACTS.md`
|
|
93
|
+
- If missing → stop and emit a CONTRACTS CHANGE PROPOSAL
|
|
94
|
+
- Never define submission payload types locally inside a form
|
|
95
|
+
|
|
96
|
+
### 5. Destructive Action Check
|
|
97
|
+
|
|
98
|
+
Does this task modify or replace an existing form?
|
|
99
|
+
|
|
100
|
+
If yes, before touching any file:
|
|
101
|
+
```
|
|
102
|
+
## DESTRUCTIVE ACTION - CONFIRMATION REQUIRED
|
|
103
|
+
This task will modify:
|
|
104
|
+
- <form name or file>
|
|
105
|
+
- <what fields or validation rules will change>
|
|
106
|
+
- <what will be removed or replaced>
|
|
107
|
+
Awaiting explicit confirmation to proceed.
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
### 6. Size & Atomicity Check
|
|
111
|
+
|
|
112
|
+
Is this task too large for one reliable pass?
|
|
113
|
+
|
|
114
|
+
If the task spans more than one form or includes both form architecture
|
|
115
|
+
and submission handling as distinct concerns:
|
|
116
|
+
```
|
|
117
|
+
## TASK BREAKDOWN PROPOSED
|
|
118
|
+
This task is too large for one pass. Suggested sequence:
|
|
119
|
+
1. <subtask A>
|
|
120
|
+
2. <subtask B>
|
|
121
|
+
3. <subtask C>
|
|
122
|
+
Proceeding with subtask 1. Confirm to continue after each step.
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
---
|
|
126
|
+
|
|
127
|
+
## Operating Principles
|
|
128
|
+
|
|
129
|
+
These apply to every form task regardless of framework.
|
|
130
|
+
|
|
131
|
+
- **Derive form patterns from resolved stack** - apply `{{FRAMEWORK}}`
|
|
132
|
+
idiomatic form handling without needing explicit instruction per task.
|
|
133
|
+
Examples: Reactive Forms in Angular, React Hook Form in React,
|
|
134
|
+
VeeValidate in Vue.
|
|
135
|
+
|
|
136
|
+
- **Validation is colocated with the form** - validation rules live with
|
|
137
|
+
the form definition, not scattered across components or services.
|
|
138
|
+
|
|
139
|
+
- **One form, one responsibility** - a form handles one user action.
|
|
140
|
+
Never bundle unrelated fields into a single form unit.
|
|
141
|
+
|
|
142
|
+
- **Error messages are user-facing** - validation error text must be
|
|
143
|
+
clear, specific, and actionable. Never expose raw validation keys.
|
|
144
|
+
|
|
145
|
+
- **Submission payloads match CONTRACTS.md** - the shape sent to the
|
|
146
|
+
backend must match the type defined in `shared/types/`. Never infer
|
|
147
|
+
or redefine the payload shape locally.
|
|
148
|
+
|
|
149
|
+
- **Form state is local** - form state lives within the form unit itself.
|
|
150
|
+
Do not push form state into global state management unless the framework
|
|
151
|
+
or task explicitly requires it.
|
|
152
|
+
|
|
153
|
+
- **Duplicate submission prevention** - every form must guard against
|
|
154
|
+
double submission. Disable the submit action while a submission is
|
|
155
|
+
in flight.
|
|
156
|
+
|
|
157
|
+
<!-- @annotation
|
|
158
|
+
Add project-specific form conventions here.
|
|
159
|
+
Examples: shared validator functions, custom error display patterns,
|
|
160
|
+
consent or confirmation dialog requirements before submission,
|
|
161
|
+
field-level debounce conventions.
|
|
162
|
+
-->
|
|
163
|
+
|
|
164
|
+
---
|
|
165
|
+
|
|
166
|
+
## Workflow
|
|
167
|
+
|
|
168
|
+
```
|
|
169
|
+
explore → summarize → plan → execute → validate
|
|
170
|
+
```
|
|
171
|
+
|
|
172
|
+
**Explore**
|
|
173
|
+
Read existing forms in the codebase before writing anything.
|
|
174
|
+
Understand current field patterns, validation approach, and submission handling.
|
|
175
|
+
|
|
176
|
+
**Summarize**
|
|
177
|
+
In 2-3 sentences, state what exists, what is missing, and what will be built.
|
|
178
|
+
Surface this before writing any code.
|
|
179
|
+
|
|
180
|
+
**Plan**
|
|
181
|
+
List fields, validation rules, and submission behavior explicitly.
|
|
182
|
+
Confirm the plan before proceeding - form architecture decisions are
|
|
183
|
+
harder to reverse than most UI changes.
|
|
184
|
+
|
|
185
|
+
**Execute**
|
|
186
|
+
Build field definitions first, then validation, then submission handling.
|
|
187
|
+
Do not mix these concerns in one pass.
|
|
188
|
+
|
|
189
|
+
**Validate**
|
|
190
|
+
After each form:
|
|
191
|
+
- Confirm all fields validate correctly against their rules
|
|
192
|
+
- Confirm error messages are clear and user-facing
|
|
193
|
+
- Confirm submission payload matches the type in `CONTRACTS.md`
|
|
194
|
+
- Confirm double submission is prevented
|
|
195
|
+
|
|
196
|
+
---
|
|
197
|
+
|
|
198
|
+
## Safety Rules
|
|
199
|
+
|
|
200
|
+
- Never define submission payload types locally - use `CONTRACTS.md`
|
|
201
|
+
- Never expose raw validation keys as user-facing error messages
|
|
202
|
+
- Never allow double submission - always guard the submit action
|
|
203
|
+
- Never push form state into global state without explicit justification
|
|
204
|
+
- Never modify a form outside the current task's stated scope
|
|
205
|
+
- Surface best-practice observations once - never loop on them
|
|
206
|
+
|
|
207
|
+
---
|
|
208
|
+
|
|
209
|
+
## Communication
|
|
210
|
+
|
|
211
|
+
| Situation | Action |
|
|
212
|
+
|----------------------------------|------------------------------------------------|
|
|
213
|
+
| Task is ambiguous | Clarification request (max 2 rounds) |
|
|
214
|
+
| Task bleeds into another domain | Scope redirect, await direction |
|
|
215
|
+
| Dependency is missing | Dependency alert, await resolution |
|
|
216
|
+
| Submission type missing | CONTRACTS CHANGE PROPOSAL, write and proceed |
|
|
217
|
+
| Existing form will change | Destructive action confirmation |
|
|
218
|
+
| Task is too large | Breakdown proposal, execute one step at a time |
|
|
219
|
+
| Best practice deviation found | Surface once, await confirmation, move on |
|
|
220
|
+
|
|
221
|
+
---
|
|
222
|
+
|
|
223
|
+
## Definition of Done
|
|
224
|
+
|
|
225
|
+
A form task is complete when:
|
|
226
|
+
|
|
227
|
+
- [ ] All planned fields exist with correct validation rules
|
|
228
|
+
- [ ] Error messages are clear, specific, and user-facing
|
|
229
|
+
- [ ] Submission payload matches the type defined in `CONTRACTS.md`
|
|
230
|
+
- [ ] Double submission is prevented
|
|
231
|
+
- [ ] Form state is local unless explicitly justified otherwise
|
|
232
|
+
- [ ] No payload types redeclared locally
|
|
233
|
+
- [ ] Code follows `{{FRAMEWORK}}` idiomatic form patterns
|
|
234
|
+
- [ ] Pre-flight checks all passed and documented if any flags were raised
|
|
235
|
+
|
|
236
|
+
---
|
|
237
|
+
|
|
238
|
+
## Session Close
|
|
239
|
+
|
|
240
|
+
When all Definition of Done items are checked:
|
|
241
|
+
|
|
242
|
+
1. Mark TASK.md complete: change `[ ] COMPLETED` to `[x] COMPLETED` at the top of TASK.md
|
|
243
|
+
2. Run: `npm run complete`
|
|
244
|
+
|
|
245
|
+
**Next recommended agent:** client/ROUTING
|