@hegemonart/get-design-done 1.41.5 → 1.43.0

package/reference/form-patterns.md

@@ -1,27 +1,27 @@
 # Form Patterns
 
-Forms are one of the highest-friction surfaces in any product. Every unnecessary click, ambiguous label, or poorly-timed error message is a conversion lost or a user abandoned mid-task. The patterns below are grounded in empirical research — primarily Luke Wroblewski's eye-tracking studies, WCAG 2.1 requirements, and NCSC/NIST guidance on authentication UX.
+Forms are one of the highest-friction surfaces in any product. Every unnecessary click, ambiguous label, or poorly-timed error message is a conversion lost or a user abandoned mid-task. The patterns below are grounded in empirical research - primarily Luke Wroblewski's eye-tracking studies, WCAG 2.1 requirements, and NCSC/NIST guidance on authentication UX.
 
 ---
 
 ## 1. Label Position
 
-Wroblewski's eye-tracking research measured the number of eye fixations required to move from label to field across the three common label placements. The findings are decisive: top-aligned labels are fastest because the eye travels in one direction — down — without a horizontal context switch.
+Wroblewski's eye-tracking research measured the number of eye fixations required to move from label to field across the three common label placements. The findings are decisive: top-aligned labels are fastest because the eye travels in one direction - down - without a horizontal context switch.
 
 **Top-aligned labels** are the default for most forms. Completion time is fastest because the label and input form a single vertical unit. They also accommodate longer translated strings without breaking layout, making them the correct default for internationalised products. Use top-aligned labels whenever form complexity is moderate to high or field types are mixed.
 
-**See:** [`./i18n.md`](./i18n.md) §Locale Formatting for the full `Intl.*` family (`NumberFormat`, `DateTimeFormat`, `PluralRules`, `RelativeTimeFormat`, `ListFormat`) over hand-rolled string concatenation — never assemble locale-aware strings via template literals. §Text Expansion explains the +30–40% LTR budget that top-aligned labels accommodate.
+**See:** [`./i18n.md`](./i18n.md) §Locale Formatting for the full `Intl.*` family (`NumberFormat`, `DateTimeFormat`, `PluralRules`, `RelativeTimeFormat`, `ListFormat`) over hand-rolled string concatenation - never assemble locale-aware strings via template literals. §Text Expansion explains the +30–40% LTR budget that top-aligned labels accommodate.
 
-**Left-aligned labels** create the slowest completion time because the eye must saccade horizontally from label to field on every row. They earn their place only when scannability of values matters more than speed — settings pages, data-entry tables, or read-heavy forms where users compare label and value together. In these contexts the horizontal alignment aids review, not input.
+**Left-aligned labels** create the slowest completion time because the eye must saccade horizontally from label to field on every row. They earn their place only when scannability of values matters more than speed - settings pages, data-entry tables, or read-heavy forms where users compare label and value together. In these contexts the horizontal alignment aids review, not input.
 
-**Floating labels (Material 3 style)** are an acceptable middle ground when screen real estate is severely constrained. The label begins as visible hint text above the field and remains visible (shrunk, repositioned) after the user starts typing. This pattern is distinct from — and incompatible with — placeholder-as-label. Never use placeholder text as the sole label: when the field receives focus the placeholder disappears, leaving the user to recall what was asked. This is a WCAG 2.1 failure under criterion 1.3.5 (Identify Input Purpose) and a general usability failure on any form longer than three fields.
+**Floating labels (Material 3 style)** are an acceptable middle ground when screen real estate is severely constrained. The label begins as visible hint text above the field and remains visible (shrunk, repositioned) after the user starts typing. This pattern is distinct from - and incompatible with - placeholder-as-label. Never use placeholder text as the sole label: when the field receives focus the placeholder disappears, leaving the user to recall what was asked. This is a WCAG 2.1 failure under criterion 1.3.5 (Identify Input Purpose) and a general usability failure on any form longer than three fields.
 
 | Label position | Completion speed | Best use case |
 |---|---|---|
 | Top-aligned | Fastest | Most forms; mixed field types; long forms |
 | Left-aligned | Slowest | Settings pages; data comparison; values matter |
 | Floating (Material 3) | Medium | Space-constrained mobile forms |
-| Placeholder-only | — | **Never** — WCAG 1.3.5 failure |
+| Placeholder-only | - | **Never** - WCAG 1.3.5 failure |
 
 ---
 
@@ -31,23 +31,23 @@ The timing of inline validation determines whether it helps or hinders. Validate
 
 **On-submit only** carries the lowest cognitive load during form completion and is appropriate for short forms (three fields or fewer). The cost is UX debt on long forms: when multiple fields fail at once, the user must scroll up to find errors, fix one, scroll back, and repeat. Provide an error summary at the top if using submit-only validation on long forms (see Section 3).
 
-**On-blur (field exit)** is the recommended default for most forms. Validation fires after the user leaves the field, not while they are in it. This prevents the jarring experience of an error appearing mid-keystroke. The critical rule: never validate on first focus — only after the field has been blurred at least once. A pristine, untouched field should never show an error state.
+**On-blur (field exit)** is the recommended default for most forms. Validation fires after the user leaves the field, not while they are in it. This prevents the jarring experience of an error appearing mid-keystroke. The critical rule: never validate on first focus - only after the field has been blurred at least once. A pristine, untouched field should never show an error state.
 
-**On-change (real-time)** is appropriate for two specific cases: password strength meters and character counters. It is not appropriate for format validation such as email addresses. Validating email format on every keystroke flags `hello@` as invalid before the user has finished typing the domain — a false negative that erodes trust in the form.
+**On-change (real-time)** is appropriate for two specific cases: password strength meters and character counters. It is not appropriate for format validation such as email addresses. Validating email format on every keystroke flags `hello@` as invalid before the user has finished typing the domain - a false negative that erodes trust in the form.
 
 Never show a red error state before the user has had a realistic opportunity to complete the field. The error state is a signal that something is wrong; triggering it prematurely teaches users to ignore it.
 
 | Timing | When to use | When to avoid |
 |---|---|---|
 | On-submit | Short forms (≤ 3 fields) | Long multi-section forms |
-| On-blur | Default for most fields | — |
+| On-blur | Default for most fields | - |
 | On-change | Password strength, character count | Format validation (email, phone) |
 
 ---
 
 ## 3. Error Placement and Recovery Copy
 
-Errors placed far from their source — in a top banner, a modal, or a footer — force the user to map the error message back to the problematic field. Errors belong immediately below the field they describe, appearing between the field and the next element in the flow.
+Errors placed far from their source - in a top banner, a modal, or a footer - force the user to map the error message back to the problematic field. Errors belong immediately below the field they describe, appearing between the field and the next element in the flow.
 
 **Visual treatment**: error messages must never rely on color alone. A red border communicates nothing to users with red-green color deficiency. Use an error icon alongside the message text. The field border color change is acceptable as a supplemental indicator, not the primary one.
 
@@ -83,7 +83,7 @@ Marking required fields unambiguously prevents submission errors and sets accura
 
 The **asterisk (*) convention** is the web default. Mark every required field with `*` and place the legend "* Required" near the top of the form, before the first field. Users arriving mid-page may not see a legend placed at the bottom.
 
-The **"(optional)" alternative** is better when most fields are required and only a few are not. Marking three optional fields "(optional)" is less visual noise than marking fifteen fields with `*`. Choose one convention per form — never mix both. A form that marks some fields `*` and labels others "(optional)" implies that unlabelled fields are neither required nor optional, which is simply confusing.
+The **"(optional)" alternative** is better when most fields are required and only a few are not. Marking three optional fields "(optional)" is less visual noise than marking fifteen fields with `*`. Choose one convention per form - never mix both. A form that marks some fields `*` and labels others "(optional)" implies that unlabelled fields are neither required nor optional, which is simply confusing.
 
 Regardless of which visual convention is used, every required field must carry `aria-required="true"` or the native `required` attribute. Screen readers announce the required state from these attributes, not from the visible asterisk.
 
@@ -103,17 +103,17 @@ Multi-step forms break long processes into manageable stages, but they introduce
 
 **Show total step count upfront** and maintain it throughout. "Step 2 of 4" gives the user a completion model. Never add steps mid-flow; if a conditional step becomes necessary, it must have been accounted for in the total from the beginning. Surprise steps feel like bait-and-switch.
 
-**Preserve state between steps** unconditionally. Browser back must restore the previous step with all previously-entered values intact. Losing data on back-navigation is one of the most damaging patterns in multi-step forms — it destroys user trust and forces re-entry of work already done. Use session storage, URL state, or in-memory state managed at the form's root level.
+**Preserve state between steps** unconditionally. Browser back must restore the previous step with all previously-entered values intact. Losing data on back-navigation is one of the most damaging patterns in multi-step forms - it destroys user trust and forces re-entry of work already done. Use session storage, URL state, or in-memory state managed at the form's root level.
 
 **Allow non-linear completion where the domain permits.** If a user wants to skip to step 3 and complete step 2 later, let them. Stepped progress indicators (like a horizontal stepper component) should be interactive links, not decorative labels, unless there is a hard dependency that makes out-of-order completion genuinely impossible.
 
-**Summary step before final submission.** Any multi-step form that results in a consequential action — purchase, account creation, booking — should include a review step that shows all entered values before the commit action. The CTA on the summary step should name the action ("Place order", "Create account") not just "Submit".
+**Summary step before final submission.** Any multi-step form that results in a consequential action - purchase, account creation, booking - should include a review step that shows all entered values before the commit action. The CTA on the summary step should name the action ("Place order", "Create account") not just "Submit".
 
 ---
 
-## 6. Autofill Hints — `autocomplete` Taxonomy
+## 6. Autofill Hints - `autocomplete` Taxonomy
 
-The `autocomplete` attribute tells the browser — and password managers, autofill services, and mobile OS keyboards — exactly what category of data a field expects. Proper use of `autocomplete` tokens reduces form completion time by 15–30% in controlled studies, primarily because browsers and password managers can populate multiple fields in a single tap. Always pair each token with the correct `input type`.
+The `autocomplete` attribute tells the browser - and password managers, autofill services, and mobile OS keyboards - exactly what category of data a field expects. Proper use of `autocomplete` tokens reduces form completion time by 15–30% in controlled studies, primarily because browsers and password managers can populate multiple fields in a single tap. Always pair each token with the correct `input type`.
 
 | Token | Meaning | Recommended `input type` |
 |---|---|---|
@@ -140,7 +140,7 @@ For address fields that are split across multiple inputs, use the sub-tokens (`a
 
 ## 7. Input Mode and Enter Key Hints
 
-On mobile devices, `inputmode` controls which virtual keyboard the OS presents, independently of the input's semantic type. `enterkeyhint` controls the label shown on the Enter/Go key. Both attributes are pure UX signals — they carry no validation meaning — and they cost nothing to add.
+On mobile devices, `inputmode` controls which virtual keyboard the OS presents, independently of the input's semantic type. `enterkeyhint` controls the label shown on the Enter/Go key. Both attributes are pure UX signals - they carry no validation meaning - and they cost nothing to add.
 
 ### `inputmode` values
 
@@ -185,7 +185,7 @@ Password fields carry more UX debt than almost any other input type, largely due
 
 **Show/hide toggle** is mandatory on any password field. The eye icon is the standard affordance. Both states must have accessible labels: `aria-label="Show password"` and `aria-label="Hide password"`. The toggle should be positioned as a button inside the trailing edge of the input, using `type="button"` to prevent accidental form submission.
 
-**Never block paste** on password fields. The UK National Cyber Security Centre (NCSC) explicitly recommends against paste-blocking. The rationale is simple: blocking paste discourages the use of password managers, which in turn pushes users toward shorter, simpler, more memorable — and therefore weaker — passwords. Paste-blocking does not prevent any known attack vector on the server side. Remove any `onpaste="return false"` or equivalent.
+**Never block paste** on password fields. The UK National Cyber Security Centre (NCSC) explicitly recommends against paste-blocking. The rationale is simple: blocking paste discourages the use of password managers, which in turn pushes users toward shorter, simpler, more memorable - and therefore weaker - passwords. Paste-blocking does not prevent any known attack vector on the server side. Remove any `onpaste="return false"` or equivalent.
 
 **Password strength meters** belong on new-password creation flows only. Displaying a strength meter on a login form reveals information about the stored password and adds noise to a flow where speed matters. Use `zxcvbn` or an equivalent entropy-based library rather than simple length/character-class rules, which users learn to game (e.g., "Password1!" satisfies most naive rules but is trivially guessable).
 
@@ -211,18 +211,18 @@ Password fields carry more UX debt than almost any other input type, largely due
 
 These three patterns all involve the user acknowledging an outcome, but they operate at different risk levels and require different interaction costs to match.
 
-**Consent checkboxes** govern communication preferences and data use. For marketing communications, the checkbox must be unchecked by default — opt-in is required under GDPR and comparable legislation in most jurisdictions. Pre-checked opt-out is only permissible for certain transactional communications or in jurisdictions that explicitly permit it; assume opt-in required unless legal has confirmed otherwise. The checkbox label must be specific about what the user is consenting to — "I agree to receive marketing emails from Acme Ltd." rather than "I accept the terms."
+**Consent checkboxes** govern communication preferences and data use. For marketing communications, the checkbox must be unchecked by default - opt-in is required under GDPR and comparable legislation in most jurisdictions. Pre-checked opt-out is only permissible for certain transactional communications or in jurisdictions that explicitly permit it; assume opt-in required unless legal has confirmed otherwise. The checkbox label must be specific about what the user is consenting to - "I agree to receive marketing emails from Acme Ltd." rather than "I accept the terms."
 
-**Confirmation dialogs** are appropriate for irreversible actions that affect data the user owns — deleting a file, cancelling a subscription, archiving a project. The confirmation dialog must state exactly what will happen. "Are you sure?" is not a confirmation. "Delete the project 'Website Redesign'? This cannot be undone." is a confirmation. The destructive action button should be visually distinct (typically red or a warning tone) and should not be the default focused element.
+**Confirmation dialogs** are appropriate for irreversible actions that affect data the user owns - deleting a file, cancelling a subscription, archiving a project. The confirmation dialog must state exactly what will happen. "Are you sure?" is not a confirmation. "Delete the project 'Website Redesign'? This cannot be undone." is a confirmation. The destructive action button should be visually distinct (typically red or a warning tone) and should not be the default focused element.
 
-**Destructive-confirmation with typed phrase** applies to catastrophic, irreversible operations: deleting an account, purging all data, permanently revoking access. Require the user to type a specific phrase — the account name, the word "DELETE", the number of items being erased — before the action becomes available. This pattern exists not to prevent accidents but to ensure the user is making a conscious, deliberate decision. GitHub, Heroku, and most infrastructure tools use this pattern for account deletion. The required phrase should be shown plainly; do not require the user to guess it.
+**Destructive-confirmation with typed phrase** applies to catastrophic, irreversible operations: deleting an account, purging all data, permanently revoking access. Require the user to type a specific phrase - the account name, the word "DELETE", the number of items being erased - before the action becomes available. This pattern exists not to prevent accidents but to ensure the user is making a conscious, deliberate decision. GitHub, Heroku, and most infrastructure tools use this pattern for account deletion. The required phrase should be shown plainly; do not require the user to guess it.
 
 | Risk level | Pattern | Example |
 |---|---|---|
-| Low — reversible | None needed | Moving a file to trash |
-| Medium — data loss possible | Confirmation dialog with specific text | Deleting a saved draft |
-| High — irreversible | Dialog + destructive button style | Cancelling a paid subscription |
-| Critical — catastrophic | Dialog + type-to-confirm phrase | Deleting an account and all its data |
+| Low - reversible | None needed | Moving a file to trash |
+| Medium - data loss possible | Confirmation dialog with specific text | Deleting a saved draft |
+| High - irreversible | Dialog + destructive button style | Cancelling a paid subscription |
+| Critical - catastrophic | Dialog + type-to-confirm phrase | Deleting an account and all its data |
 
 ---
 
@@ -232,9 +232,9 @@ CAPTCHA presents a genuine tension: friction added to stop bots is friction expe
 
 **Invisible CAPTCHA v3** (Google reCAPTCHA v3, Cloudflare Turnstile, hCaptcha Invisible) is the preferred approach. These services score user behaviour in the background and surface a challenge only when the risk score exceeds a threshold. Typical deployments have challenge rates under 1% for real users. There is no visible puzzle, no audio fallback needed for the happy path.
 
-**When a visible challenge is unavoidable**, WCAG 1.1.1 requires a non-visual alternative. Every visual CAPTCHA must have an audio alternative that is solvable with a screen reader and no visual ability. Text-based CAPTCHAs distorted beyond normal variance effectively exclude users with dyslexia and cognitive disabilities — treat this as a legal and ethical risk, not just a UX inconvenience.
+**When a visible challenge is unavoidable**, WCAG 1.1.1 requires a non-visual alternative. Every visual CAPTCHA must have an audio alternative that is solvable with a screen reader and no visual ability. Text-based CAPTCHAs distorted beyond normal variance effectively exclude users with dyslexia and cognitive disabilities - treat this as a legal and ethical risk, not just a UX inconvenience.
 
-**Time-limited CAPTCHAs** — those that expire while a slow or motor-impaired user is completing them — are inaccessible by design and should never be used. If a CAPTCHA session can time out, the user must be able to request a refresh without losing their form data.
+**Time-limited CAPTCHAs** - those that expire while a slow or motor-impaired user is completing them - are inaccessible by design and should never be used. If a CAPTCHA session can time out, the user must be able to request a refresh without losing their form data.
 
 **Progressive trust** is the most human approach for authenticated flows. A logged-in user with a verified email and account history presents a negligible bot risk. Do not require CAPTCHA from authenticated users unless there is a specific elevated-risk action (e.g., a bulk API call or mass send). Reserve CAPTCHA friction for unauthenticated, rate-limited, or anomalous-behaviour scenarios.
 

package/reference/framer-motion-patterns.md

@@ -2,20 +2,20 @@
 
 # Framer Motion Patterns
 
-Framer Motion is the standard animation library for React. It abstracts the browser's animation primitives into a declarative API that stays out of your way for common cases while exposing full physics-based control when you need it. This reference covers implementation patterns — not just the API, but _why_ each pattern exists and when to apply it.
+Framer Motion is the standard animation library for React. It abstracts the browser's animation primitives into a declarative API that stays out of your way for common cases while exposing full physics-based control when you need it. This reference covers implementation patterns - not just the API, but _why_ each pattern exists and when to apply it.
 
 ---
 
-## 1. Basics — motion components
+## 1. Basics - motion components
 
 Any HTML (or SVG) element can become a motion component by prefixing it with `motion.`. The most common variants are `motion.div`, `motion.span`, `motion.button`, and `motion.li`, but `motion.section`, `motion.a`, `motion.img`, and any other HTML element follow the same pattern.
 
 The four primary animation props are:
 
-- **`initial`** — the state the element starts in before it mounts (or before a transition begins). Without `initial`, the element won't animate _from_ anything — it'll just be in the `animate` state on mount. Always provide `initial` when you want an entrance animation.
-- **`animate`** — the state the element should animate _to_. Framer drives the element toward this state whenever it changes.
-- **`exit`** — the state the element animates _to_ when it unmounts. Requires `<AnimatePresence>` as a parent — see Section 3.
-- **`transition`** — controls how the animation happens (spring, tween, duration, ease). If omitted, Framer applies a spring by default for layout/positional changes and a tween for opacity.
+- **`initial`** - the state the element starts in before it mounts (or before a transition begins). Without `initial`, the element won't animate _from_ anything - it'll just be in the `animate` state on mount. Always provide `initial` when you want an entrance animation.
+- **`animate`** - the state the element should animate _to_. Framer drives the element toward this state whenever it changes.
+- **`exit`** - the state the element animates _to_ when it unmounts. Requires `<AnimatePresence>` as a parent - see Section 3.
+- **`transition`** - controls how the animation happens (spring, tween, duration, ease). If omitted, Framer applies a spring by default for layout/positional changes and a tween for opacity.
 
 A basic fade-in example:
 
@@ -35,17 +35,17 @@ function FadeIn({ children }: { children: React.ReactNode }) {
 }
 ```
 
-The slight `y: 8` offset on entry gives the element a sense of emerging from below — a common, subtle entrance pattern. The `easeOut` ease starts fast and slows at the end, which feels responsive.
+The slight `y: 8` offset on entry gives the element a sense of emerging from below - a common, subtle entrance pattern. The `easeOut` ease starts fast and slows at the end, which feels responsive.
 
 ---
 
 ## 2. Spring vs. Tween Configuration
 
-Framer Motion supports two fundamentally different animation models. Choosing between them is not arbitrary — each has a domain where it clearly wins.
+Framer Motion supports two fundamentally different animation models. Choosing between them is not arbitrary - each has a domain where it clearly wins.
 
 ### Spring physics (preferred for UI motion)
 
-Springs model the physics of a real spring: the element overshoots slightly and settles. This is why spring motion _feels natural_ — real objects in the world have inertia and settle under physical forces. For UI, spring motion communicates responsiveness and quality.
+Springs model the physics of a real spring: the element overshoots slightly and settles. This is why spring motion _feels natural_ - real objects in the world have inertia and settle under physical forces. For UI, spring motion communicates responsiveness and quality.
 
 `type: "spring"` is Framer's default for layout animations and positional changes. Key parameters:
 
@@ -54,10 +54,10 @@ Springs model the physics of a real spring: the element overshoots slightly and
 - **`mass`** (0.5–2): adds inertia. Higher mass makes the element feel heavier and slower to respond.
 
 The relationship that matters in practice:
-- **High stiffness + high damping = snappy** — fast arrival, no bounce. This is the production UI default.
-- **Low stiffness + low damping = bouncy** — never use in production UI. Bounce feels playful and toy-like, which is wrong for most product contexts.
+- **High stiffness + high damping = snappy** - fast arrival, no bounce. This is the production UI default.
+- **Low stiffness + low damping = bouncy** - never use in production UI. Bounce feels playful and toy-like, which is wrong for most product contexts.
 
-**Hard constraint: `bounce: 0` always for icon cross-fades and micro-interactions.** The `bounce` shorthand parameter is a convenience alias — setting it to 0 ensures no oscillation. "Bounce must be zero" is a non-negotiable rule for any interaction that fires frequently or in information-dense UI.
+**Hard constraint: `bounce: 0` always for icon cross-fades and micro-interactions.** The `bounce` shorthand parameter is a convenience alias - setting it to 0 ensures no oscillation. "Bounce must be zero" is a non-negotiable rule for any interaction that fires frequently or in information-dense UI.
 
 Recommended production preset:
 
@@ -69,16 +69,16 @@ This is snappy and clean. It arrives fast and settles without any visible oscill
 
 ### Tween (for duration-controlled, eased animations)
 
-Tween animations run over a fixed duration with a specified easing curve. Use them when exact timing matters — opacity fades, color transitions, anything where you need predictable, duration-controlled behavior rather than physics.
+Tween animations run over a fixed duration with a specified easing curve. Use them when exact timing matters - opacity fades, color transitions, anything where you need predictable, duration-controlled behavior rather than physics.
 
 ```tsx
 transition={{ type: 'tween', duration: 0.2, ease: 'easeOut' }}
 ```
 
 Ease guidance:
-- **`"easeOut"`** for entrances — starts fast (feels responsive), decelerates to rest.
-- **`"easeIn"`** for exits — accelerates away, gets out of the way quickly.
-- **`"easeInOut"`** for emphasis transitions — smooth acceleration and deceleration, used when the same element transitions between states (not entering/exiting).
+- **`"easeOut"`** for entrances - starts fast (feels responsive), decelerates to rest.
+- **`"easeIn"`** for exits - accelerates away, gets out of the way quickly.
+- **`"easeInOut"`** for emphasis transitions - smooth acceleration and deceleration, used when the same element transitions between states (not entering/exiting).
 
 The rule of thumb: use springs for movement and scale; use tweens for opacity, color, and blur.
 
@@ -86,7 +86,7 @@ The rule of thumb: use springs for movement and scale; use tweens for opacity, c
 
 ## 3. AnimatePresence
 
-`AnimatePresence` is the component that enables exit animations. Without it, React unmounts components immediately, and `exit` props are never executed — the element simply vanishes.
+`AnimatePresence` is the component that enables exit animations. Without it, React unmounts components immediately, and `exit` props are never executed - the element simply vanishes.
 
 ```tsx
 import { AnimatePresence, motion } from 'framer-motion'
@@ -116,13 +116,13 @@ Every child of `AnimatePresence` that will be conditionally rendered **must have
 
 The `mode` prop controls how entering and exiting elements interact during a transition:
 
-- **`mode: "wait"`** — the exiting element completes its exit animation fully before the entering element begins its entrance. Use this for route transitions and tab panel swaps, where showing two elements simultaneously would be confusing.
-- **`mode: "sync"`** — enter and exit animations run simultaneously. Use this when you're swapping UI elements (like icon cross-fades) and want both transitions to happen at once.
-- **`mode: "popLayout"`** — the exiting element immediately pops out of the document flow so surrounding elements can animate into their new positions right away, while the exiting element still plays its exit animation. Ideal for list item removal.
+- **`mode: "wait"`** - the exiting element completes its exit animation fully before the entering element begins its entrance. Use this for route transitions and tab panel swaps, where showing two elements simultaneously would be confusing.
+- **`mode: "sync"`** - enter and exit animations run simultaneously. Use this when you're swapping UI elements (like icon cross-fades) and want both transitions to happen at once.
+- **`mode: "popLayout"`** - the exiting element immediately pops out of the document flow so surrounding elements can animate into their new positions right away, while the exiting element still plays its exit animation. Ideal for list item removal.
 
 ### Critical rule: `<AnimatePresence initial={false}>`
 
-When `AnimatePresence` wraps persistent UI that already exists on first render — like a tab panel that's visible on page load, or a sidebar that's open by default — you must pass `initial={false}`:
+When `AnimatePresence` wraps persistent UI that already exists on first render - like a tab panel that's visible on page load, or a sidebar that's open by default - you must pass `initial={false}`:
 
 ```tsx
 <AnimatePresence initial={false}>
@@ -134,13 +134,13 @@ When `AnimatePresence` wraps persistent UI that already exists on first render
 </AnimatePresence>
 ```
 
-Without `initial={false}`, every component inside `AnimatePresence` will play its entrance animation on first mount, even when the user didn't trigger it. This is jarring and wrong — **never animate on initial load for existing UI**.
+Without `initial={false}`, every component inside `AnimatePresence` will play its entrance animation on first mount, even when the user didn't trigger it. This is jarring and wrong - **never animate on initial load for existing UI**.
 
 ---
 
 ## 4. Layout Animations
 
-The `layout` prop is one of Framer Motion's most powerful features. Add `layout` to a `motion` component, and Framer automatically detects when the component's position or size changes in the DOM and animates it from the old layout to the new one — even if the change was caused by other elements shifting around it.
+The `layout` prop is one of Framer Motion's most powerful features. Add `layout` to a `motion` component, and Framer automatically detects when the component's position or size changes in the DOM and animates it from the old layout to the new one - even if the change was caused by other elements shifting around it.
 
 ```tsx
 <motion.div layout className="card">
@@ -150,7 +150,7 @@ The `layout` prop is one of Framer Motion's most powerful features. Add `layout`
 
 When `isExpanded` changes, Framer measures the old and new layouts and smoothly animates the transition. This works for position changes caused by sibling elements reordering, parent resizing, or content toggling.
 
-**`layoutId` — shared element transitions:** Assign the same `layoutId` to two different components, and Framer will morph between them when one unmounts and the other mounts. This is the canonical implementation for expanding card → detail transitions and hero → full-view animations.
+**`layoutId` - shared element transitions:** Assign the same `layoutId` to two different components, and Framer will morph between them when one unmounts and the other mounts. This is the canonical implementation for expanding card → detail transitions and hero → full-view animations.
 
 ```tsx
 // Card in list view
@@ -160,7 +160,7 @@ When `isExpanded` changes, Framer measures the old and new layouts and smoothly
 <motion.img layoutId={`product-image-${id}`} src={fullImage} />
 ```
 
-When the list-view card unmounts and the modal mounts, Framer animates the image from its list-view position to its modal position. The two components don't need to coexist — the transition bridges the gap.
+When the list-view card unmounts and the modal mounts, Framer animates the image from its list-view position to its modal position. The two components don't need to coexist - the transition bridges the gap.
 
 **Important:** ensure only one component with a given `layoutId` is mounted at a time. Two simultaneously mounted components with the same `layoutId` will fight each other and produce broken animations.
 
@@ -206,9 +206,9 @@ function AnimatedList({ items }) {
 }
 ```
 
-**Propagation:** When a parent has `variants` and `animate="visible"`, child `motion` components that also have `variants` will automatically receive the same `animate` value — they don't need their own `animate` prop. Framer propagates the state name down the tree.
+**Propagation:** When a parent has `variants` and `animate="visible"`, child `motion` components that also have `variants` will automatically receive the same `animate` value - they don't need their own `animate` prop. Framer propagates the state name down the tree.
 
-**`staggerChildren`** delays each child's animation start by the specified seconds after the previous child. A value of `0.05` means each item enters 50ms after the previous — the standard for list entrance animations. More than `0.08` seconds starts to feel slow; more than 6–8 items should stagger in parallel (`staggerChildren` + `staggerDirection` with a cap).
+**`staggerChildren`** delays each child's animation start by the specified seconds after the previous child. A value of `0.05` means each item enters 50ms after the previous - the standard for list entrance animations. More than `0.08` seconds starts to feel slow; more than 6–8 items should stagger in parallel (`staggerChildren` + `staggerDirection` with a cap).
 
 **`delayChildren`** adds an initial delay before the first child begins, which gives the parent time to render visibly before its children start entering.
 
@@ -218,7 +218,7 @@ function AnimatedList({ items }) {
 
 Framer Motion provides props that animate elements in response to user gestures without requiring event handlers or state.
 
-**`whileHover`:** The animation state while the pointer is hovering. Prefer subtle transforms — `scale: 1.02` for a gentle grow or `y: -2` for a subtle lift. Avoid large scale values (> 1.05) on UI elements; they feel unstable.
+**`whileHover`:** The animation state while the pointer is hovering. Prefer subtle transforms - `scale: 1.02` for a gentle grow or `y: -2` for a subtle lift. Avoid large scale values (> 1.05) on UI elements; they feel unstable.
 
 ```tsx
 <motion.button whileHover={{ scale: 1.02 }} transition={{ type: 'spring', stiffness: 400, damping: 30 }}>
@@ -238,7 +238,7 @@ Framer Motion provides props that animate elements in response to user gestures
 </motion.button>
 ```
 
-**`drag` + `dragConstraints`:** Enable drag with `drag` (either `true`, `"x"`, or `"y"`), and bound the drag region with `dragConstraints`. Use `dragElastic: 0.1` for a subtle resistance when dragging beyond the constraint boundaries — this gives physical feedback that the user has reached an edge.
+**`drag` + `dragConstraints`:** Enable drag with `drag` (either `true`, `"x"`, or `"y"`), and bound the drag region with `dragConstraints`. Use `dragElastic: 0.1` for a subtle resistance when dragging beyond the constraint boundaries - this gives physical feedback that the user has reached an edge.
 
 ```tsx
 <motion.div
@@ -289,13 +289,13 @@ Use `style={{ y }}` (not `animate`) for scroll-linked values because `animate` c
 </motion.section>
 ```
 
-**`viewport={{ once: true }}`** is the preferred option for entrance animations — the element animates in once and stays visible. Without `once: true`, the element will animate every time it enters the viewport, which is usually wrong for entrance effects (and can feel janky during fast scrolling).
+**`viewport={{ once: true }}`** is the preferred option for entrance animations - the element animates in once and stays visible. Without `once: true`, the element will animate every time it enters the viewport, which is usually wrong for entrance effects (and can feel janky during fast scrolling).
 
 ---
 
 ## 8. prefers-reduced-motion Compliance
 
-Respecting `prefers-reduced-motion` is **mandatory** for accessibility compliance. Some users have vestibular disorders or motion sensitivity — for them, unnecessary motion causes real physical discomfort. This is not optional polish; it is a WCAG 2.1 requirement.
+Respecting `prefers-reduced-motion` is **mandatory** for accessibility compliance. Some users have vestibular disorders or motion sensitivity - for them, unnecessary motion causes real physical discomfort. This is not optional polish; it is a WCAG 2.1 requirement.
 
 ### Per-component approach with `useReducedMotion`
 
@@ -321,11 +321,11 @@ function AnimatedCard() {
 }
 ```
 
-When `prefersReducedMotion` is true, set `duration: 0` and remove any positional animation values — the element should appear instantly without motion.
+When `prefersReducedMotion` is true, set `duration: 0` and remove any positional animation values - the element should appear instantly without motion.
 
 ### App-wide approach with `MotionConfig` (preferred)
 
-The cleanest solution for most applications is to wrap the app root with `MotionConfig` using `reducedMotion: "user"`. This instructs Framer to automatically apply reduced-motion behavior for all motion components in the subtree when the OS preference is set — no per-component logic needed.
+The cleanest solution for most applications is to wrap the app root with `MotionConfig` using `reducedMotion: "user"`. This instructs Framer to automatically apply reduced-motion behavior for all motion components in the subtree when the OS preference is set - no per-component logic needed.
 
 ```tsx
 import { MotionConfig } from 'framer-motion'
@@ -339,18 +339,18 @@ function App() {
 }
 ```
 
-`reducedMotion: "user"` reads the OS setting via `prefers-reduced-motion` media query and disables animations globally when it's set. This is the preferred approach because it's zero-maintenance — adding new animated components automatically inherits the behavior.
+`reducedMotion: "user"` reads the OS setting via `prefers-reduced-motion` media query and disables animations globally when it's set. This is the preferred approach because it's zero-maintenance - adding new animated components automatically inherits the behavior.
 
 ---
 
 ## 9. 60fps Performance Rules
 
-Animation performance on the web comes down to a single principle: **only animate properties that the browser can handle on the GPU compositor thread**. Everything else requires the browser to recalculate layout or repaint pixels — work that happens on the main thread and causes dropped frames.
+Animation performance on the web comes down to a single principle: **only animate properties that the browser can handle on the GPU compositor thread**. Everything else requires the browser to recalculate layout or repaint pixels - work that happens on the main thread and causes dropped frames.
 
 ### Properties that are GPU-safe (always use these)
 
-- `x`, `y` — map to `translateX()` and `translateY()` in `transform`
-- `scale`, `scaleX`, `scaleY` — map to `scale()` in `transform`
+- `x`, `y` - map to `translateX()` and `translateY()` in `transform`
+- `scale`, `scaleX`, `scaleY` - map to `scale()` in `transform`
 - `rotate`, `rotateX`, `rotateY`, `rotateZ`
 - `skewX`, `skewY`
 - `opacity`
@@ -359,17 +359,17 @@ These properties run on the compositor thread and never block the main thread, r
 
 ### Properties that cause jank (never animate these)
 
-- `width`, `height` — triggers layout recalculation on every frame
-- `margin`, `padding` — shifts surrounding elements, triggers full reflow
+- `width`, `height` - triggers layout recalculation on every frame
+- `margin`, `padding` - shifts surrounding elements, triggers full reflow
 - `border-width`
-- `left`, `top`, `right`, `bottom` (on positioned elements) — triggers layout
-- `font-size` — triggers layout and repaint
+- `left`, `top`, `right`, `bottom` (on positioned elements) - triggers layout
+- `font-size` - triggers layout and repaint
 
-If you need to animate a size change, use `scale` on a wrapper. If you need to animate position, use `x`/`y` rather than `left`/`top`. This distinction is why Framer's layout animation system (Section 4) works — it uses `transform` internally even when responding to layout-driven position changes.
+If you need to animate a size change, use `scale` on a wrapper. If you need to animate position, use `x`/`y` rather than `left`/`top`. This distinction is why Framer's layout animation system (Section 4) works - it uses `transform` internally even when responding to layout-driven position changes.
 
 ### `will-change: transform`
 
-Only add `will-change: transform` when you observe a first-frame stutter on a specific element. Do not add it preemptively — it forces the browser to allocate a separate GPU layer for the element immediately, consuming GPU memory whether or not the animation is actually playing. Reserve it for elements with known performance issues after profiling.
+Only add `will-change: transform` when you observe a first-frame stutter on a specific element. Do not add it preemptively - it forces the browser to allocate a separate GPU layer for the element immediately, consuming GPU memory whether or not the animation is actually playing. Reserve it for elements with known performance issues after profiling.
 
 ---
 
@@ -377,9 +377,9 @@ Only add `will-change: transform` when you observe a first-frame stutter on a sp
 
 `MotionConfig` is a context provider that configures all `motion` components within its subtree. Use it for:
 
-- **Reduced motion compliance** — as shown in Section 8, `reducedMotion: "user"` is the cleanest global solution.
-- **Global transition defaults** — set a default transition for all motion components so individual components don't need to repeat the same `transition` prop.
-- **Custom ease functions** — define a custom cubic-bezier ease once and reference it by name throughout the tree.
+- **Reduced motion compliance** - as shown in Section 8, `reducedMotion: "user"` is the cleanest global solution.
+- **Global transition defaults** - set a default transition for all motion components so individual components don't need to repeat the same `transition` prop.
+- **Custom ease functions** - define a custom cubic-bezier ease once and reference it by name throughout the tree.
 
 ```tsx
 <MotionConfig
@@ -398,14 +398,14 @@ With this configuration, every `motion` component that doesn't specify its own `
 
 These are the mistakes that appear most frequently in codebases using Framer Motion:
 
-**Missing `initial` with `animate`:** If you add `animate={{ opacity: 1 }}` without `initial={{ opacity: 0 }}`, the element is already at opacity 1 on mount — there's nothing to animate from. Always pair `animate` with `initial` when you want an entrance effect.
+**Missing `initial` with `animate`:** If you add `animate={{ opacity: 1 }}` without `initial={{ opacity: 0 }}`, the element is already at opacity 1 on mount - there's nothing to animate from. Always pair `animate` with `initial` when you want an entrance effect.
 
 **Missing `key` props in `AnimatePresence`:** Exit animations will silently not fire if children of `AnimatePresence` don't have `key` props. Framer can't identify which element is leaving without a stable key.
 
 **Variant propagation only reaches `motion` children:** Parent variants propagate to child `motion` components, but not to plain HTML children or non-motion React components. If a list item is a plain `<li>` instead of `<motion.li>`, it won't receive the parent's variant orchestration.
 
-**`layoutId` conflicts:** If two components with the same `layoutId` are both mounted simultaneously — even briefly during a transition — Framer doesn't know which is the source and which is the target. The result is erratic, broken animation. Ensure mutual exclusivity: when one mounts, the other must have already unmounted.
+**`layoutId` conflicts:** If two components with the same `layoutId` are both mounted simultaneously - even briefly during a transition - Framer doesn't know which is the source and which is the target. The result is erratic, broken animation. Ensure mutual exclusivity: when one mounts, the other must have already unmounted.
 
-**Unnecessary `AnimatePresence` nesting:** Nesting `AnimatePresence` inside another `AnimatePresence` complicates exit orchestration — inner exits may not complete before outer exits begin. Keep the tree flat; use a single `AnimatePresence` at the appropriate level.
+**Unnecessary `AnimatePresence` nesting:** Nesting `AnimatePresence` inside another `AnimatePresence` complicates exit orchestration - inner exits may not complete before outer exits begin. Keep the tree flat; use a single `AnimatePresence` at the appropriate level.
 
 **Wrapping everything in `motion.div`:** `motion.div` carries a slightly larger bundle footprint than a plain `div` because it registers the element with Framer's animation engine. Don't wrap static, unanimated elements. Only wrap elements that actually need animation. Reserve `motion.*` for elements where animation provides genuine value.

package/reference/gdd-runtime-audit.md

@@ -1,15 +1,15 @@
 # GDD Runtime Static Security Audit
 
-**Phase:** 33.5 — GDD Runtime Security Hardening · **Plan:** 33.5-02 (Wave A) · **Date:** 2026-05-31
+**Phase:** 33.5 - GDD Runtime Security Hardening · **Plan:** 33.5-02 (Wave A) · **Date:** 2026-05-31
 **Reference:** branch `phase/33-5-runtime-security`
-**Scope:** the SHIPPED runtime surface — `hooks/`, `scripts/`, `sdk/`, `bin/`.
+**Scope:** the SHIPPED runtime surface - `hooks/`, `scripts/`, `sdk/`, `bin/`.
 **Method:** static enumeration (read-only source inspection, no execution, no network).
 **Companions:**
 
-- `scripts/security/outbound-allowlist.json` — the machine-readable, CANONICAL active-egress
+- `scripts/security/outbound-allowlist.json` - the machine-readable, CANONICAL active-egress
   allowlist that Phase 33.5-04's `scripts/scan-outbound-network.cjs` gate `JSON.parse`s (this
   report is its human-readable rationale).
-- `reference/gdd-threat-model.md` — the STRIDE threat model (Phase 33.5-01).
+- `reference/gdd-threat-model.md` - the STRIDE threat model (Phase 33.5-01).
 
 This audit freezes the egress / secret / external-input picture so any *future* surface that is
 not pre-approved trips the 33.5-04 gate at CI time. It is grounded in the CONTEXT real-tree sweep
@@ -21,10 +21,10 @@ not pre-approved trips the 33.5-04 gate at CI time. It is grounded in the CONTEX
 
 GDD's runtime makes outbound calls (or local IPC/server binds) from exactly the sites below. Each
 maps to an `outbound-allowlist.json` directory glob (see the **Allowlisted** column). The 33.5-04
-gate is **ACTIVE-egress-only** — it matches `require`/`import` of `node:http(s)`/`http(s)`/`ws`/
+gate is **ACTIVE-egress-only** - it matches `require`/`import` of `node:http(s)`/`http(s)`/`ws`/
 `node-fetch`/`axios`/`undici`, `fetch(`, `http(s).get/.request(`, `new WebSocket`/`new
 WebSocketServer`/`WebSocketServer(`, and child-process `spawn`/`spawnSync`/`exec*` of
-`gh|curl|wget|nc|ssh|scp` — so a bare URL string alone never trips it.
+`gh|curl|wget|nc|ssh|scp` - so a bare URL string alone never trips it.
 
 | File | What it calls | Transport | Legitimacy | Allowlisted by |
 | --- | --- | --- | --- | --- |
@@ -40,7 +40,7 @@ WebSocketServer`/`WebSocketServer(`, and child-process `spawn`/`spawnSync`/`exec
 | `scripts/e2e/run-headless.ts` | live Anthropic API run | REST (key-gated) | Test infrastructure only; gated on `ANTHROPIC_API_KEY` + main-branch; never in default `npm test` | `scripts/e2e/**` |
 | `scripts/lib/authority-watcher/index.cjs` | authority-feed classification of already-fetched records | (delegated) | The live article fetch is delegated to `agents/design-authority-watcher.md`; `index.cjs` is the pure-CommonJS classifier. Allowlisted so any direct feed fetch added here stays pre-approved | `scripts/lib/authority-watcher/**` |
 
-**Documented but NOT hard-gated** (the scanner scope is `.js`-family + active-egress only —
+**Documented but NOT hard-gated** (the scanner scope is `.js`-family + active-egress only -
 these cannot exfiltrate on their own and are covered by gitleaks + the threat model):
 
 | File / surface | What it is | Why not gated |
@@ -50,8 +50,8 @@ these cannot exfiltrate on their own and are covered by gitleaks + the threat mo
 | `scripts/lib/install/merge.cjs` (line 85) | "Plugin repository: https://github.com/hegemonart/get-design-done" printed string | bare URL string, no call |
 | `scripts/lib/issue-reporter/destination.cjs` (lines 29–30) | frozen `DESTINATION_URL` / `ISSUE_TEMPLATE_URL` constants | constants consumed only via the `gh` spawn above |
 | `scripts/lint-agentskills-spec.cjs` (line 76) | spec-example URL in a comment | bare URL string, no call |
-| `hooks/update-check.sh` | shell update-check egress | shell script — outside the `.{js,cjs,mjs,ts}` scanner scope |
-| `scripts/bootstrap.sh` | shell bootstrap egress | shell script — outside the `.{js,cjs,mjs,ts}` scanner scope |
+| `hooks/update-check.sh` | shell update-check egress | shell script - outside the `.{js,cjs,mjs,ts}` scanner scope |
+| `scripts/bootstrap.sh` | shell bootstrap egress | shell script - outside the `.{js,cjs,mjs,ts}` scanner scope |
 
 ---
 
@@ -64,7 +64,7 @@ Where a token/key/credential is read, forwarded, or scrubbed across the shipped
 | `scripts/lib/redact.cjs` | PEM, JWT, Anthropic `sk-ant-`, Stripe `sk_live_`, Slack `xox*`, GitHub `ghp_`, AWS `AKIA`, generic `sk-` (8 patterns) | **scrub** | Deep-walks event-stream payloads at serialize time so everything that hits disk / a bus subscriber is `[REDACTED:<type>]`. **D-07 extends** with Gemini `AIza…`, GitHub fine-grained `github_pat_`, and GitHub `ghs_/gho_/ghu_/ghr_` (currently uncovered). |
 | `scripts/lib/peer-cli/acp-client.cjs` (line 102) | full `process.env` | **forward** (default) | `const env = opts.env … : process.env` → GDD's `ANTHROPIC_API_KEY`/`GH_TOKEN`/`GDD_*` leak to a spawned peer when `opts.env` is absent. **Fixed by 33.5-04** (allowlist-forward, default-deny, shared `sanitize-env`). |
 | `scripts/lib/peer-cli/asp-client.cjs` (line 122) | full `process.env` | **forward** (default) | Same default-inherit gap; same 33.5-04 fix. |
-| `scripts/lib/figma-extract/pull.cjs` | `FIGMA_TOKEN` / `FIGMA_PERSONAL_ACCESS_TOKEN` | **read** | Lives only inside caller-provided `headers`; NEVER written to disk, NEVER logged (diagnostics read a short body prefix, never the token — D-10 of the figma sub-plan). |
+| `scripts/lib/figma-extract/pull.cjs` | `FIGMA_TOKEN` / `FIGMA_PERSONAL_ACCESS_TOKEN` | **read** | Lives only inside caller-provided `headers`; NEVER written to disk, NEVER logged (diagnostics read a short body prefix, never the token - D-10 of the figma sub-plan). |
 | `scripts/lib/issue-reporter/gh-submit.cjs` / `dedup.cjs` | none held by GDD | **delegate** | Authentication is `gh`'s own logged-in credential store; GDD never reads or forwards a GitHub token for these spawns. |
 
 ---
@@ -77,32 +77,32 @@ Where untrusted data crosses a trust boundary into GDD's runtime.
 | --- | --- | --- | --- |
 | WebSocket upgrade request | a remote client connecting to the event-stream WS | `scripts/lib/transports/ws.cjs` HTTP `upgrade` handler | Bearer-token gate (≥8 chars) already ships; **33.5-03** adds 127.0.0.1-default bind + timing-safe compare so the default config does not expose `0.0.0.0`. |
 | gdd-state MCP tool inputs | the MCP client / model | `sdk/mcp/gdd-state/tools/*.ts` (11 tools) + `tools/shared.ts` | Each tool has a JSON schema under `sdk/mcp/gdd-state/schemas/`; **33.5-08** tightens them (`additionalProperties:false` + `maxLength`) and adds a payload-size cap (JSON-bomb guard). |
-| `GDD_STATE_PATH` env override | the launching environment | `sdk/mcp/gdd-state/tools/shared.ts:resolveStatePath()` (line 60–61) | `process.env['GDD_STATE_PATH'] ?? .design/STATE.md` with **no path-traversal guard** today — `..`/absolute-outside escape is unchecked. **Closed by 33.5-08** (resolve + assert within project root / `.design/`). |
+| `GDD_STATE_PATH` env override | the launching environment | `sdk/mcp/gdd-state/tools/shared.ts:resolveStatePath()` (line 60–61) | `process.env['GDD_STATE_PATH'] ?? .design/STATE.md` with **no path-traversal guard** today - `..`/absolute-outside escape is unchecked. **Closed by 33.5-08** (resolve + assert within project root / `.design/`). |
 | `.design/config.json` | a repo-local config file (potentially attacker-influenced in a malicious clone) | 14 modules incl. `scripts/lib/peer-cli/registry.cjs` (line 154) | Drives `peer_cli.enabled_peers` / (33.5) `peer_cli.env_allowlist`, the WS `event_stream.bind_host`, and the issue-reporter kill-switch. Parsed defensively; opt-in by design (a peer must be explicitly enabled). |
-| peer child `stdout` | a spawned LOCAL peer CLI | `scripts/lib/peer-cli/acp-client.cjs` (JSON-RPC frame parser) | A malicious/buggy peer could flood stdout — **already capped at 16 MiB un-newlined** (DoS guard). JSON-RPC frames are parsed, not `eval`'d. |
+| peer child `stdout` | a spawned LOCAL peer CLI | `scripts/lib/peer-cli/acp-client.cjs` (JSON-RPC frame parser) | A malicious/buggy peer could flood stdout - **already capped at 16 MiB un-newlined** (DoS guard). JSON-RPC frames are parsed, not `eval`'d. |
 
 ---
 
 ## Finding
 
 The legitimate active-egress set is fully enumerated above and **no raw unexpected egress was
-found** — every outbound call, server bind, or child spawn maps to one of six trusted modules,
+found** - every outbound call, server bind, or child spawn maps to one of six trusted modules,
 each frozen into `scripts/security/outbound-allowlist.json` with a justification. The allowlist
 uses **directory globs** so a new helper in an already-trusted module (e.g. another
 `figma-extract` file) does not silently trip the gate, and every glob is asserted by
-`test/suite/phase-33-5-audit.test.cjs` to resolve to ≥1 real file — so the 33.5-04 gate cannot be
+`test/suite/phase-33-5-audit.test.cjs` to resolve to ≥1 real file - so the 33.5-04 gate cannot be
 defeated by a stale entry that matches nothing.
 
 The residual gaps surfaced here are **closed by the remaining Phase 33.5 plans**:
 
-- **33.5-03** — WebSocket bind hardening: 127.0.0.1 default bind (no more `0.0.0.0`), opt-in remote
+- **33.5-03** - WebSocket bind hardening: 127.0.0.1 default bind (no more `0.0.0.0`), opt-in remote
   via `event_stream.bind_host`, and a timing-safe (`crypto.timingSafeEqual`) token compare. Closes
   the WS-upgrade external-input row.
-- **33.5-04** — Outbound-network static CI gate: `scripts/scan-outbound-network.cjs` +
+- **33.5-04** - Outbound-network static CI gate: `scripts/scan-outbound-network.cjs` +
   `npm run scan:outbound`, consuming THIS plan's `outbound-allowlist.json`. Also lands the
   peer-CLI env-allowlist sandbox (shared `sanitize-env`) that closes the `acp-client.cjs` /
   `asp-client.cjs` full-`process.env` forward rows.
-- **33.5-05** (and 33.5-07/08) — secret-scan extension (Gemini + GitHub fine-grained/server
+- **33.5-05** (and 33.5-07/08) - secret-scan extension (Gemini + GitHub fine-grained/server
   tokens) with a synthetic-secret fuzz, the gdd-state path-traversal guard + payload cap +
   tightened schemas, `SECURITY.md`, and the regression baseline.