@zigrivers/scaffold 3.6.0 → 3.8.0

package/content/knowledge/web-app/web-app-testing.md

@@ -0,0 +1,249 @@
+---
+name: web-app-testing
+description: Component testing with Testing Library, SSR testing, E2E testing with Playwright, visual regression, accessibility testing with axe-core, and Lighthouse CI
+topics: [web-app, testing, playwright, testing-library, accessibility, visual-regression, lighthouse, e2e]
+---
+
+Web application testing requires covering multiple distinct layers: component behavior, server rendering correctness, end-to-end user flows, visual appearance, accessibility compliance, and performance budgets. Each layer catches different classes of bugs and has different cost/value characteristics. The correct strategy invests heavily in component and integration tests (fast feedback, high coverage), uses E2E tests for critical user journeys (slow but comprehensive), and enforces visual and performance budgets in CI (catches regressions before users do).
+
+## Summary
+
+### Testing Layers
+
+**Component tests (Testing Library):** Test components in isolation from the DOM's perspective — interactions, rendering, and state changes. These form the bulk of the test suite. Use `@testing-library/user-event` for realistic interactions, not `fireEvent`.
+
+**Integration tests:** Test pages or feature slices with real data flow but mocked network calls. Verify that components interact correctly. In Next.js: test pages as React components with a mocked router.
+
+**SSR tests (render-to-string):** Verify server-rendered HTML is correct and does not throw. Check that SSR and hydration produce consistent output (no hydration mismatches). Use `@testing-library/react`'s `renderToStaticMarkup` or framework-specific utilities.
+
+**E2E tests (Playwright):** Test complete user flows in a real browser against a running application. Reserve for high-value, business-critical flows: registration, login, checkout, core product value proposition. Keep the E2E suite small and fast (target under 10 minutes for the critical path).
+
+**Visual regression tests:** Screenshot comparison against committed baselines. Catch unintended UI changes from CSS refactors, component updates, or dependency upgrades. Run against a static Storybook deployment for fast, stable comparisons.
+
+**Accessibility tests (axe-core):** Automated WCAG compliance checking. Catches ~30–40% of accessibility issues automatically. Not a substitute for manual testing with a screen reader, but essential for catching regressions.
+
+**Performance tests (Lighthouse CI):** Enforce performance budgets in CI. Fail the build if LCP, CLS, or INP regressions are detected.
+
+### Testing Library Principles
+
+Testing Library is designed around the principle that tests should resemble how users interact with the application:
+
+- **Query by role first** — `getByRole('button', { name: 'Submit' })` over `getByTestId`
+- **Query by label text** — `getByLabelText('Email address')` for form inputs
+- **Never query by CSS class** — classes are implementation details, not behavior
+- **Use `userEvent` not `fireEvent`** — `userEvent.type()` simulates real keystrokes including focus, blur, and change events; `fireEvent` dispatches synthetic events that skip browser behaviors
+
+### Playwright for E2E
+
+Playwright supports Chromium, Firefox, and WebKit. Configure it to run against your staging environment in CI and your local dev server locally. Key features:
+- Auto-waiting: Playwright automatically waits for elements to be ready before interacting
+- Network mocking: intercept and mock API responses in tests
+- Trace viewer: visual debugging of test failures with full network and DOM timeline
+- Component testing: Playwright can also test components in isolation (alternative to Testing Library for teams that want one tool)
+
+## Deep Guidance
+
+### Component Testing Patterns
+
+```typescript
+// UserProfile.test.tsx — Testing Library patterns
+import { render, screen, waitFor } from '@testing-library/react';
+import userEvent from '@testing-library/user-event';
+import { UserProfile } from './UserProfile';
+import { server } from '@/mocks/server';  // MSW mock server
+import { http, HttpResponse } from 'msw';
+
+describe('UserProfile', () => {
+  it('displays user data after loading', async () => {
+    render(<UserProfile userId="user-123" />);
+
+    // Loading state
+    expect(screen.getByRole('status')).toBeInTheDocument();
+
+    // Data loads
+    await screen.findByText('Jane Smith');  // Awaits element appearance
+    expect(screen.getByText('jane@example.com')).toBeInTheDocument();
+    expect(screen.queryByRole('status')).not.toBeInTheDocument();
+  });
+
+  it('allows editing the display name', async () => {
+    const user = userEvent.setup();
+    render(<UserProfile userId="user-123" />);
+
+    await screen.findByText('Jane Smith');
+    await user.click(screen.getByRole('button', { name: 'Edit profile' }));
+
+    const nameInput = screen.getByLabelText('Display name');
+    await user.clear(nameInput);
+    await user.type(nameInput, 'Jane Doe');
+    await user.click(screen.getByRole('button', { name: 'Save changes' }));
+
+    await screen.findByText('Profile updated successfully');
+    expect(screen.getByText('Jane Doe')).toBeInTheDocument();
+  });
+
+  it('shows an error message when the save fails', async () => {
+    // Override the default MSW handler for this test
+    server.use(
+      http.patch('/api/users/:id', () =>
+        HttpResponse.json({ error: 'Server error' }, { status: 500 })
+      )
+    );
+
+    const user = userEvent.setup();
+    render(<UserProfile userId="user-123" />);
+
+    await screen.findByText('Jane Smith');
+    await user.click(screen.getByRole('button', { name: 'Edit profile' }));
+    await user.click(screen.getByRole('button', { name: 'Save changes' }));
+
+    await screen.findByRole('alert');
+    expect(screen.getByText(/something went wrong/i)).toBeInTheDocument();
+  });
+});
+```
+
+Use Mock Service Worker (MSW) for network mocking — it intercepts requests at the network level, making tests work identically in browser and Node environments.
+
+### Playwright E2E Tests
+
+```typescript
+// tests/e2e/auth.spec.ts — Playwright E2E for critical auth flow
+import { test, expect } from '@playwright/test';
+
+test.describe('Authentication', () => {
+  test('user can register and log in', async ({ page }) => {
+    const email = `test-${Date.now()}@example.com`;
+
+    // Registration
+    await page.goto('/register');
+    await page.getByLabel('Email address').fill(email);
+    await page.getByLabel('Password').fill('SecureP@ss123');
+    await page.getByLabel('Confirm password').fill('SecureP@ss123');
+    await page.getByRole('button', { name: 'Create account' }).click();
+
+    // Should redirect to onboarding
+    await expect(page).toHaveURL('/onboarding');
+    await expect(page.getByText('Welcome')).toBeVisible();
+
+    // Log out
+    await page.getByRole('button', { name: 'Account menu' }).click();
+    await page.getByRole('menuitem', { name: 'Sign out' }).click();
+    await expect(page).toHaveURL('/');
+
+    // Log in
+    await page.goto('/login');
+    await page.getByLabel('Email address').fill(email);
+    await page.getByLabel('Password').fill('SecureP@ss123');
+    await page.getByRole('button', { name: 'Sign in' }).click();
+
+    await expect(page).toHaveURL('/dashboard');
+  });
+
+  test('shows error for invalid credentials', async ({ page }) => {
+    await page.goto('/login');
+    await page.getByLabel('Email address').fill('nonexistent@example.com');
+    await page.getByLabel('Password').fill('wrongpassword');
+    await page.getByRole('button', { name: 'Sign in' }).click();
+
+    await expect(page.getByRole('alert')).toContainText('Invalid email or password');
+    await expect(page).toHaveURL('/login');
+  });
+});
+```
+
+### Accessibility Testing with axe-core
+
+```typescript
+// Integrate axe-core into component tests
+import { render } from '@testing-library/react';
+import { axe, toHaveNoViolations } from 'jest-axe';
+
+expect.extend(toHaveNoViolations);
+
+describe('Accessibility', () => {
+  it('LoginForm has no accessibility violations', async () => {
+    const { container } = render(<LoginForm />);
+    const results = await axe(container);
+    expect(results).toHaveNoViolations();
+  });
+});
+
+// Playwright accessibility snapshot
+test('dashboard is accessible', async ({ page }) => {
+  await page.goto('/dashboard');
+  const accessibilityScanResults = await new AxeBuilder({ page })
+    .withTags(['wcag2a', 'wcag2aa'])
+    .analyze();
+  expect(accessibilityScanResults.violations).toEqual([]);
+});
+```
+
+Axe-core checks: missing alt text, insufficient color contrast, missing form labels, improper heading hierarchy, keyboard navigation issues, and ARIA attribute misuse. Run it against every page in CI.
+
+### Lighthouse CI Configuration
+
+```yaml
+# lighthouserc.yml
+ci:
+  collect:
+    url:
+      - 'http://localhost:3000/'
+      - 'http://localhost:3000/dashboard'
+    numberOfRuns: 3  # Average across multiple runs for stability
+    settings:
+      preset: 'desktop'
+      throttling:
+        rttMs: 40
+        throughputKbps: 10240
+        cpuSlowdownMultiplier: 1
+
+  assert:
+    preset: 'lighthouse:no-pwa'
+    assertions:
+      # Core Web Vitals
+      largest-contentful-paint:
+        - error
+        - maxNumericValue: 2500
+          aggregationMethod: optimistic  # Use best of N runs
+      cumulative-layout-shift:
+        - error
+        - maxNumericValue: 0.1
+      total-blocking-time:
+        - warn
+        - maxNumericValue: 300
+
+      # Performance budget
+      uses-optimized-images: ['warn', { minScore: 0.9 }]
+      uses-text-compression: ['error', { minScore: 1 }]
+      render-blocking-resources: ['warn', { minScore: 0.8 }]
+
+      # Accessibility
+      categories:accessibility: ['error', { minScore: 0.9 }]
+```
+
+Run Lighthouse CI in a separate CI step after deployment to your staging environment. Fail only on errors (hard regressions); warn on improvements.
+
+### SSR Hydration Testing
+
+```typescript
+// Verify SSR output and hydration consistency
+import { renderToString } from 'react-dom/server';
+import { render } from '@testing-library/react';
+
+test('ProductCard renders consistently in SSR and client', () => {
+  const props = { name: 'Widget', price: 29.99 };
+
+  // SSR render
+  const ssrHTML = renderToString(<ProductCard {...props} />);
+
+  // Client render
+  const { container } = render(<ProductCard {...props} />);
+
+  // Compare — normalize whitespace differences
+  const normalize = (html: string) => html.replace(/\s+/g, ' ').trim();
+  expect(normalize(container.innerHTML)).toBe(normalize(ssrHTML));
+});
+```
+
+Hydration mismatches produce React warnings in development and can cause visual flicker in production. Test SSR/client consistency for any component that uses `Date.now()`, `Math.random()`, browser APIs, or dynamic imports.

package/content/knowledge/web-app/web-app-ux-patterns.md

@@ -0,0 +1,162 @@
+---
+name: web-app-ux-patterns
+description: Responsive design, loading states, error boundaries, offline patterns, optimistic updates, and accessibility (WCAG) for web apps
+topics: [web-app, ux, responsive-design, loading-states, error-handling, accessibility, wcag, offline, optimistic-updates]
+---
+
+UX patterns are the difference between an app that users trust and one they abandon. The patterns covered here are not visual design choices — they are engineering decisions about how the app communicates state, handles failure, and responds to interaction. Implement them consistently across the entire app or they create a fragmented user experience that signals poor quality.
+
+## Summary
+
+UX patterns cover responsive mobile-first design, loading states (skeletons, progressive loading, optimistic updates), error boundaries at meaningful granularity, offline patterns for PWAs, and accessibility compliance. Implement these consistently across the entire app. Loading states for sub-100ms operations make the app feel slower; omit them.
+
+## Deep Guidance
+
+### Responsive Design: Mobile-First
+
+Design and implement for mobile first, then add complexity for larger screens. This discipline prevents the "desktop first, mobile afterthought" failure mode:
+
+```css
+/* Mobile default: full width stack */
+.product-grid {
+  display: grid;
+  grid-template-columns: 1fr;
+  gap: var(--sp-4);
+}
+
+/* Tablet: 2 columns */
+@media (min-width: 768px) {
+  .product-grid {
+    grid-template-columns: repeat(2, 1fr);
+  }
+}
+
+/* Desktop: 3 columns */
+@media (min-width: 1024px) {
+  .product-grid {
+    grid-template-columns: repeat(3, 1fr);
+  }
+}
+```
+
+Touch targets must be at least 44 x 44 px (Apple HIG) or 48 x 48 px (Material Design). Smaller tap targets on mobile cause accidental taps and user frustration. This is both a UX and accessibility requirement.
+
+Viewport-relative units (`vw`, `vh`, `svh`, `dvh`) handle mobile browser chrome (address bars, bottom navigation) correctly. Use `dvh` for full-height layouts on mobile — `100vh` overflows when the browser chrome is visible.
+
+### Loading States
+
+Never show a blank screen or unresponsive UI during data fetching. Use the appropriate loading pattern for the context:
+
+- **Skeleton screens**: Render a content-shaped placeholder that mirrors the final layout. Reduces perceived load time and prevents layout shift when content arrives. Preferred over spinners for content that has a predictable layout.
+- **Progressive loading**: Render low-quality or partial content immediately, replace with full content as it loads. Image blur-up (blur-hash placeholder to full image) is a common example.
+- **Inline spinners**: For user-triggered actions (button submit, form save) where a skeleton does not make sense. Keep spinners small and contextual — a full-page spinner on a button press is jarring.
+- **Optimistic updates**: Show the result immediately, apply it to the server in the background (see below). Best perceived performance.
+
+Never show a loading state for actions that complete under 100 ms. Adding a spinner to fast operations makes the app feel slower.
+
+### Error Boundaries
+
+React error boundaries prevent a single component crash from destroying the entire page:
+
+```tsx
+// components/ErrorBoundary.tsx
+class ErrorBoundary extends React.Component<
+  { fallback: ReactNode; children: ReactNode },
+  { hasError: boolean }
+> {
+  state = { hasError: false };
+
+  static getDerivedStateFromError() {
+    return { hasError: true };
+  }
+
+  componentDidCatch(error: Error, info: ErrorInfo) {
+    reportError(error, info);  // Send to Sentry, Datadog, etc.
+  }
+
+  render() {
+    if (this.state.hasError) return this.props.fallback;
+    return this.props.children;
+  }
+}
+```
+
+Place error boundaries at meaningful granularity: one per major page section, not one per component (too granular) and not one per app (too coarse). When the sidebar crashes, the main content should still work.
+
+Provide actionable fallback UIs: "Something went wrong" with a Retry button, not a blank space. Log errors to your monitoring service with full context (user ID, route, component stack) so you can fix them.
+
+### Offline Patterns
+
+If the app targets users who may lose connectivity (mobile users, field workers, PWA), design for it explicitly:
+
+- **Detect connectivity**: `navigator.onLine` and the `online`/`offline` events. React Query and SWR automatically pause requests while offline and retry on reconnect.
+- **Cache reads**: Service worker with a cache-first or stale-while-revalidate strategy for read operations. Users see the last known state instead of an error page.
+- **Queue writes**: Store mutations locally (IndexedDB via Dexie, or background sync API) and replay them when connectivity restores. Essential for field apps where users must be able to submit forms offline.
+- **Communicate status**: Show a banner when offline. Tell users which data may be stale. Do not silently fail mutations — tell the user the action is queued.
+
+Implementing offline support adds significant complexity. Scope it to the specific user journeys that need it, not the entire app.
+
+### Optimistic Updates
+
+Optimistic updates apply the result of a mutation to the UI immediately, before server confirmation:
+
+```typescript
+// React Query optimistic update pattern
+const mutation = useMutation({
+  mutationFn: updateTodo,
+  onMutate: async (newTodo) => {
+    await queryClient.cancelQueries({ queryKey: ["todos"] });
+    const previousTodos = queryClient.getQueryData(["todos"]);
+    queryClient.setQueryData(["todos"], (old) =>
+      old.map((t) => t.id === newTodo.id ? { ...t, ...newTodo } : t)
+    );
+    return { previousTodos };
+  },
+  onError: (error, variables, context) => {
+    queryClient.setQueryData(["todos"], context.previousTodos);
+    showError("Failed to save changes.");
+  },
+  onSettled: () => queryClient.invalidateQueries({ queryKey: ["todos"] }),
+});
+```
+
+Use optimistic updates for: toggling checkboxes, likes/favorites, reordering, simple field edits. Do not use for: payments, irreversible actions, or anything where showing a false success state is harmful.
+
+### Accessibility Implementation
+
+WCAG compliance is a legal requirement in many jurisdictions (ADA, EN 301 549, AODA) and a quality signal for all users:
+
+**Keyboard navigation:**
+- Every interactive element reachable by Tab key in logical order
+- Focus styles visible and high-contrast (never `outline: none` without a replacement)
+- Modal dialogs trap focus; Escape closes them
+- Custom interactive components (dropdowns, sliders, date pickers) implement ARIA keyboard patterns from the WAI-ARIA Authoring Practices Guide
+
+**Screen reader support:**
+- Semantic HTML first: `<button>` not `<div onClick>`, `<nav>` not `<div class="nav">`, `<h1>`–`<h6>` for heading hierarchy
+- `alt` text on all meaningful images; `alt=""` for decorative images
+- `aria-label` or `aria-labelledby` for elements whose text content does not describe their purpose
+- Live regions (`aria-live="polite"`) for dynamic content updates (error messages, notifications)
+- Test with VoiceOver (macOS/iOS) and NVDA (Windows) — automated tools miss 60–70% of real issues
+
+**Color and contrast:**
+- Minimum 4.5:1 contrast ratio for normal text, 3:1 for large text (WCAG AA)
+- Do not rely on color alone to convey meaning — add icons, patterns, or text labels
+
+### Form UX Patterns
+
+Forms are the highest-friction interaction in most apps. Apply these patterns:
+
+- **Inline validation**: Validate on blur (not on keystroke) to avoid distracting errors as users type. Show success states to confirm correct input.
+- **Error placement**: Show field-level errors directly below the field, not in a summary banner. Users must not hunt to find which field has an error.
+- **Label positioning**: Labels above inputs, not placeholders-as-labels. Placeholder text disappears when the user types and fails accessibility requirements.
+- **Disabled submit vs. validation feedback**: Do not disable the submit button with no explanation. Instead, allow submission and show validation errors. Disabled buttons with no label are inaccessible and frustrating.
+
+### Toast / Notification Patterns
+
+Notifications must not interrupt user flow or require dismissal for low-priority information:
+
+- **Success toasts**: Auto-dismiss after 4–5 seconds. No action required.
+- **Error toasts**: Persist until dismissed or action taken. User must be able to act on the error.
+- **Placement**: Bottom-right (desktop) or bottom-center (mobile) to avoid covering primary content.
+- **Screen reader**: Announce via `aria-live="polite"` for non-critical messages, `aria-live="assertive"` only for critical errors. Assertive announcements interrupt screen reader narration — use sparingly.

package/content/methodology/backend-overlay.yml

@@ -0,0 +1,73 @@
+# methodology/backend-overlay.yml
+name: backend
+description: >
+  Backend service overlay — injects backend domain knowledge into existing
+  pipeline steps for API design, data modeling, authentication, async
+  processing, and deployment patterns.
+project-type: backend
+
+# ---------------------------------------------------------------------------
+# knowledge-overrides
+# ---------------------------------------------------------------------------
+# Map backend knowledge entries into existing pipeline steps so that backend
+# domain expertise is injected during prompt assembly.
+knowledge-overrides:
+  # Foundational
+  create-prd:
+    append: [backend-requirements]
+  user-stories:
+    append: [backend-requirements]
+  coding-standards:
+    append: [backend-conventions]
+  project-structure:
+    append: [backend-project-structure]
+  dev-env-setup:
+    append: [backend-dev-environment]
+  git-workflow:
+    append: [backend-deployment]
+
+  # Architecture & Design
+  system-architecture:
+    append: [backend-architecture, backend-async-patterns, backend-worker-patterns]
+  tech-stack:
+    append: [backend-architecture, backend-api-design, backend-auth-patterns]
+  adrs:
+    append: [backend-architecture]
+  domain-modeling:
+    append: [backend-data-modeling]
+  database-schema:
+    append: [backend-data-modeling]
+  api-contracts:
+    append: [backend-api-design]
+  security:
+    append: [backend-auth-patterns, backend-security]
+  operations:
+    append: [backend-deployment, backend-observability, backend-async-patterns, backend-worker-patterns]
+
+  # Testing
+  tdd:
+    append: [backend-testing]
+  add-e2e-testing:
+    append: [backend-testing]
+  create-evals:
+    append: [backend-testing]
+  story-tests:
+    append: [backend-testing]
+
+  # Reviews (mirror authoring steps)
+  review-architecture:
+    append: [backend-architecture, backend-async-patterns, backend-worker-patterns]
+  review-api:
+    append: [backend-api-design]
+  review-database:
+    append: [backend-data-modeling]
+  review-security:
+    append: [backend-auth-patterns, backend-security]
+  review-operations:
+    append: [backend-deployment, backend-observability, backend-async-patterns, backend-worker-patterns]
+  review-testing:
+    append: [backend-testing]
+
+  # Planning
+  implementation-plan:
+    append: [backend-architecture]

package/content/methodology/cli-overlay.yml

@@ -0,0 +1,69 @@
+# methodology/cli-overlay.yml
+name: cli
+description: >
+  CLI tool overlay — injects CLI domain knowledge into existing pipeline
+  steps for command parsing, distribution, interactive prompts, output
+  formatting, and shell integration patterns.
+project-type: cli
+
+# ---------------------------------------------------------------------------
+# knowledge-overrides
+# ---------------------------------------------------------------------------
+# Map CLI knowledge entries into existing pipeline steps so that CLI tool
+# domain expertise is injected during prompt assembly.
+knowledge-overrides:
+  # Foundational
+  create-prd:
+    append: [cli-requirements]
+  user-stories:
+    append: [cli-requirements]
+  coding-standards:
+    append: [cli-conventions]
+  project-structure:
+    append: [cli-project-structure]
+  dev-env-setup:
+    append: [cli-dev-environment, cli-shell-integration]
+  git-workflow:
+    append: [cli-distribution-patterns]
+
+  # Architecture & Design
+  system-architecture:
+    append: [cli-architecture, cli-interactivity-patterns]
+  tech-stack:
+    append: [cli-architecture, cli-distribution-patterns]
+  adrs:
+    append: [cli-architecture]
+  domain-modeling:
+    append: [cli-architecture]
+  api-contracts:
+    append: [cli-output-patterns]
+  security:
+    append: [cli-conventions]
+  operations:
+    append: [cli-distribution-patterns, cli-shell-integration]
+
+  # Testing
+  tdd:
+    append: [cli-testing]
+  add-e2e-testing:
+    append: [cli-testing]
+  create-evals:
+    append: [cli-testing]
+  story-tests:
+    append: [cli-testing]
+
+  # Reviews (mirror authoring steps)
+  review-architecture:
+    append: [cli-architecture, cli-interactivity-patterns]
+  review-api:
+    append: [cli-output-patterns]
+  review-security:
+    append: [cli-conventions]
+  review-operations:
+    append: [cli-distribution-patterns, cli-shell-integration]
+  review-testing:
+    append: [cli-testing]
+
+  # Planning
+  implementation-plan:
+    append: [cli-architecture]

package/content/methodology/library-overlay.yml

@@ -0,0 +1,67 @@
+# methodology/library-overlay.yml
+name: library
+description: >
+  Library overlay — injects library domain knowledge into existing pipeline
+  steps for API design, bundling, type definitions, documentation, and
+  versioning patterns.
+project-type: library
+
+# ---------------------------------------------------------------------------
+# knowledge-overrides
+# ---------------------------------------------------------------------------
+# Map library knowledge entries into existing pipeline steps so that library
+# domain expertise is injected during prompt assembly.
+knowledge-overrides:
+  # Foundational
+  create-prd:
+    append: [library-requirements]
+  user-stories:
+    append: [library-requirements]
+  coding-standards:
+    append: [library-conventions, library-documentation]
+  project-structure:
+    append: [library-project-structure]
+  dev-env-setup:
+    append: [library-dev-environment]
+  git-workflow:
+    append: [library-versioning]
+
+  # Architecture & Design
+  system-architecture:
+    append: [library-architecture]
+  tech-stack:
+    append: [library-architecture, library-bundling, library-type-definitions]
+  adrs:
+    append: [library-architecture]
+  api-contracts:
+    append: [library-api-design]
+  security:
+    append: [library-security]
+  operations:
+    append: [library-versioning, library-documentation]
+
+  # Testing
+  tdd:
+    append: [library-testing]
+  add-e2e-testing:
+    append: [library-testing]
+  create-evals:
+    append: [library-testing]
+  story-tests:
+    append: [library-testing]
+
+  # Reviews (mirror authoring steps)
+  review-architecture:
+    append: [library-architecture]
+  review-api:
+    append: [library-api-design]
+  review-security:
+    append: [library-security]
+  review-operations:
+    append: [library-versioning, library-documentation]
+  review-testing:
+    append: [library-testing]
+
+  # Planning
+  implementation-plan:
+    append: [library-architecture]