jason.woltje
3ea385223e
ms-archify (evidence-based architectural mapping), ms-sdlc, ms-proactive-agent, ms-goal, ms-grill-me, ms-frontend-design.
71 lines
4.6 KiB
Markdown
71 lines
4.6 KiB
Markdown
# Verification and completion
|
|
|
|
## Evidence appropriate to the task (MUST)
|
|
|
|
For each relevant requirement record its ID or clear name, result, evidence,
|
|
and unresolved limitation. Use the existing project report or a concise
|
|
handoff; a small repair does not need a separate audit document.
|
|
|
|
- **pass:** observed behavior satisfies the requirement; identify the check.
|
|
- **fail:** observed behavior violates it; identify the problem.
|
|
- **not applicable:** the applicability condition is absent; explain why.
|
|
- **not verified:** needed access, facts, or test capability are missing.
|
|
|
|
An explicit scope exclusion is recorded as excluded with its consequence;
|
|
it does not turn an applicable requirement into an inapplicable one. Do not
|
|
average failed functional/accessibility checks into a passing aesthetic score.
|
|
|
|
## Review sequence
|
|
|
|
1. **Structure and content:** check hierarchy, truthful copy, semantic tokens,
|
|
route inventory, real link destinations, and relevant component states.
|
|
2. **Rendered behavior:** inspect representative narrow and wide viewports,
|
|
around layout transitions, with long/empty content, image/font failure,
|
|
zoom, reduced motion, and supported themes/languages as relevant.
|
|
3. **Interactions:** exercise the main task, keyboard path, submission states,
|
|
recovery, and repeated actions. Use a mock or authorized test destination
|
|
for messaging, purchases, and other external effects.
|
|
4. **Site completeness:** for site-level work, verify the inventory in
|
|
[site completeness](site-completeness.md), including direct unknown routes,
|
|
Contact, privacy, consent behavior, footer links, and year rollover.
|
|
5. **Project checks:** run relevant existing build, lint, accessibility, and
|
|
behavior checks. Add tests when they verify consequential behavior such as
|
|
consent gating or submission recovery; avoid tests that merely match copy.
|
|
6. **Critique and recheck:** correct observed problems and rerun affected
|
|
checks. Stop when the scoped acceptance conditions are met; do not add
|
|
repeated redesign rounds just to seek novelty.
|
|
|
|
Screenshots support visual claims. DOM inspection supports structural claims.
|
|
Keyboard traces support interaction claims. Network/storage checks support
|
|
consent claims. Mock responses do not prove a production delivery integration.
|
|
State those limits instead of treating one kind of evidence as another.
|
|
|
|
## Completion gate
|
|
|
|
For implemented work, do not declare the site or feature fully complete while
|
|
an applicable requirement is failed or not verified. Deliver the usable work
|
|
and name remaining limitations precisely. Do not block independent work just
|
|
because one integration or business fact is missing. Publication is governed
|
|
by the user's authorization and project workflow, not this skill.
|
|
|
|
For reviews or design-only work, completion means the requested assessment or
|
|
design is delivered with findings and limitations; it does not mean the
|
|
underlying product has passed implementation checks.
|
|
|
|
## Scenario checks for maintaining this skill
|
|
|
|
Use contrasting scenarios when substantially revising the instructions.
|
|
These describe expected decisions, not a requirement to build all scenarios
|
|
for each frontend task. Distinguish a reasoning walkthrough from an executed
|
|
evaluation with a rendered artifact.
|
|
|
|
| Scenario | Expected behavior |
|
|
| --- | --- |
|
|
| New public studio site, supplied business facts, no optional tracking | Distinctive direction; working About, Contact, privacy, footer, dynamic year, and 404. Inspect actual data use; no unnecessary consent banner. |
|
|
| Public site with consent-required analytics and a third-party video embed | Inventory both integrations; gate them before consent, permit selective choice, persist rejection, and stop future activity after withdrawal. |
|
|
| Dense internal operations dashboard | Reuse product conventions, preserve frequent controls, include relevant failure/focus/empty states, and adapt genuine two-dimensional data appropriately. Public marketing pages need a scope reason. |
|
|
| Fix one form field in an established app | Preserve the design system; fix semantics, labeling, and related error/layout behavior. Do not launch a site-wide redesign. |
|
|
| New public site with unknown operator/contact/retention facts | Ask for required facts; build independent structure; identify draft policy/contact work. Do not invent facts or claim publication readiness. |
|
|
| Static site with multiple copyright placements | Use a shared year source with a rollover/update strategy; exercise year boundary and cache behavior. Leave policy effective dates intact. |
|
|
| No browser or network-inspection capability | Perform useful implementation/static checks and explicitly mark visual, interaction, or consent checks not verified. |
|