@zigrivers/scaffold 3.28.0 → 3.30.0

package/content/knowledge/review/review-domain-modeling.md

@@ -2,6 +2,11 @@
 name: review-domain-modeling
 description: Failure modes and review passes specific to domain modeling artifacts
 topics: [domain-modeling, ddd, bounded-contexts, review]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://martinfowler.com/bliki/BoundedContext.html
 ---
 
 # Review: Domain Modeling

package/content/knowledge/review/review-game-design.md

@@ -2,6 +2,10 @@
 name: review-game-design
 description: Failure modes and review passes specific to Game Design Documents — pillar coherence, core loop closure, mechanic clarity, and scope feasibility
 topics: [game-dev, review, gdd, pillars, mechanics, scope]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Review: Game Design Document

package/content/knowledge/review/review-game-economy.md

@@ -2,6 +2,10 @@
 name: review-game-economy
 description: Failure modes and review passes specific to game economy design — inflation trajectories, exploit vectors, monetization ethics, and legal compliance
 topics: [game-dev, review, economy, balance, monetization, legal]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Review: Game Economy

package/content/knowledge/review/review-game-ui.md

@@ -2,6 +2,11 @@
 name: review-game-ui
 description: Failure modes and review passes specific to game UI specifications — HUD hierarchy, menu navigation, controller accessibility, settings coverage, FTUE effectiveness, state machine completeness, and platform shell compliance
 topics: [game-dev, review, ui, hud, menus, controller, accessibility, ftue]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://www.w3.org/WAI/standards-guidelines/wcag/
 ---
 
 # Review: Game UI Specification

package/content/knowledge/review/review-implementation-tasks.md

@@ -2,6 +2,11 @@
 name: review-implementation-tasks
 description: Failure modes and review passes specific to implementation tasks artifacts
 topics: [tasks, planning, decomposition, agents, review]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://github.com/steveyegge/beads
 ---
 
 # Review: Implementation Tasks

package/content/knowledge/review/review-methodology.md

@@ -2,6 +2,10 @@
 name: review-methodology
 description: Shared process for conducting multi-pass reviews of documentation artifacts
 topics: [methodology, quality-assurance, multi-pass, review]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Review Methodology

package/content/knowledge/review/review-netcode.md

@@ -2,6 +2,10 @@
 name: review-netcode
 description: Failure modes and review passes specific to netcode design — latency analysis, bandwidth ceilings, cheat surfaces, and disconnect handling
 topics: [game-dev, review, networking, latency, bandwidth, anticheat]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Review: Netcode Design

package/content/knowledge/review/review-operations.md

@@ -2,6 +2,12 @@
 name: review-operations
 description: Failure modes and review passes specific to operations and deployment runbook artifacts
 topics: [operations, deployment, monitoring, runbooks, review]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://sre.google/sre-book/table-of-contents/
+  - url: https://opentelemetry.io/docs/
 ---
 
 # Review: Operations & Deployment

package/content/knowledge/review/review-platform-cert.md

@@ -2,6 +2,10 @@
 name: review-platform-cert
 description: Failure modes and review passes specific to platform certification — TRC/TCR compliance, save data, suspend/resume, controller disconnect, and content ratings
 topics: [game-dev, review, certification, trc, tcr, compliance]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Review: Platform Certification

package/content/knowledge/review/review-prd.md

@@ -2,6 +2,10 @@
 name: review-prd
 description: Failure modes and review passes specific to product requirements document artifacts
 topics: [prd, requirements, completeness, clarity, nfr, constraints, review]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Review: Product Requirements Document

package/content/knowledge/review/review-security.md

@@ -2,6 +2,13 @@
 name: review-security
 description: Failure modes and review passes specific to security review and documentation artifacts
 topics: [security, owasp, auth, threat-modeling, review]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://owasp.org/Top10/
+  - url: https://owasp.org/www-project-application-security-verification-standard/
+  - url: https://www.nist.gov/cyberframework
 ---
 
 # Review: Security

package/content/knowledge/review/review-system-architecture.md

@@ -2,6 +2,12 @@
 name: review-system-architecture
 description: Failure modes and review passes specific to system architecture documents
 topics: [architecture, components, data-flow, modules, review]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://microservices.io/patterns/
+  - url: https://martinfowler.com/architecture/
 ---
 
 # Review: System Architecture

package/content/knowledge/review/review-testing-strategy.md

@@ -2,6 +2,12 @@
 name: review-testing-strategy
 description: Failure modes and review passes specific to testing and quality strategy artifacts
 topics: [testing, quality, coverage, test-pyramid, review]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://martinfowler.com/articles/practical-test-pyramid.html
+  - url: https://docs.pact.io/
 ---
 
 # Review: Testing Strategy

package/content/knowledge/review/review-user-stories.md

@@ -2,6 +2,11 @@
 name: review-user-stories
 description: Failure modes and review passes specific to user story artifacts
 topics: [user-stories, coverage, acceptance-criteria, INVEST, testability, review]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://www.agilealliance.org/glossary/invest/
 ---
 
 # Review: User Stories

package/content/knowledge/review/review-ux-specification.md

@@ -2,6 +2,12 @@
 name: review-ux-specification
 description: Failure modes and review passes specific to UI/UX specification artifacts
 topics: [ux, design, accessibility, responsive-design, review]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://www.w3.org/WAI/standards-guidelines/wcag/
+  - url: https://tr.designtokens.org/format/
 ---
 
 # Review: UX Specification

package/content/knowledge/review/review-vision.md

@@ -2,6 +2,10 @@
 name: review-vision
 description: Vision-specific review passes, failure modes, and quality criteria for product vision documents
 topics: [vision, product-strategy, validation, review]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Review: Product Vision

package/content/knowledge/tools/post-implementation-review-methodology.md

@@ -2,6 +2,10 @@
 name: post-implementation-review-methodology
 description: Two-phase whole-codebase review methodology for post-implementation quality validation
 topics: [review, code-review, multi-model, post-implementation, methodology]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Post-Implementation Review Methodology

package/content/knowledge/tools/release-management.md

@@ -2,6 +2,11 @@
 name: release-management
 description: Release engineering patterns for semantic versioning and changelog management
 topics: [release, versioning, changelog, git]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://www.conventionalcommits.org/en/v1.0.0/
 ---
 
 # Release Management

package/content/knowledge/tools/session-analysis.md

@@ -2,6 +2,10 @@
 name: session-analysis
 description: Patterns for analyzing Claude Code sessions to discover automation opportunities
 topics: [analysis, automation, sessions]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Session Analysis

package/content/knowledge/tools/version-strategy.md

@@ -2,6 +2,10 @@
 name: version-strategy
 description: Version file management across language ecosystems
 topics: [versioning, packages, ecosystems]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Version Strategy

package/content/knowledge/validation/critical-path-analysis.md

@@ -2,6 +2,10 @@
 name: critical-path-analysis
 description: Tracing critical user journeys end-to-end across all specifications
 topics: [validation, critical-path, user-journeys, end-to-end, gap-analysis]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Critical Path Analysis

package/content/knowledge/validation/cross-phase-consistency.md

@@ -2,6 +2,10 @@
 name: cross-phase-consistency
 description: Auditing consistency across pipeline phases — naming, assumptions, data flows, interface contracts
 topics: [validation, consistency, naming, data-flow, contracts]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Cross-Phase Consistency

package/content/knowledge/validation/decision-completeness.md

@@ -2,6 +2,11 @@
 name: decision-completeness
 description: Verifying all architectural decisions are recorded, justified, and non-contradictory
 topics: [validation, decisions, adr, completeness, contradictions]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://adr.github.io/
 ---
 
 # Decision Completeness

package/content/knowledge/validation/dependency-validation.md

@@ -2,6 +2,10 @@
 name: dependency-validation
 description: Verifying dependency graphs are acyclic, complete, and correctly ordered
 topics: [validation, dependencies, graphs, cycles, ordering, parallelization]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Dependency Validation

package/content/knowledge/validation/implementability-review.md

@@ -2,6 +2,10 @@
 name: implementability-review
 description: Dry-running specs as an implementing agent to catch ambiguity and missing detail
 topics: [validation, implementability, ambiguity, agent-readiness, dry-run]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Implementability Review

package/content/knowledge/validation/scope-management.md

@@ -2,6 +2,10 @@
 name: scope-management
 description: Detecting scope creep and ensuring specs stay aligned to PRD boundaries
 topics: [validation, scope, creep, prd-alignment, gold-plating]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Scope Management

package/content/knowledge/validation/traceability.md

@@ -2,6 +2,10 @@
 name: traceability
 description: Building traceability matrices from requirements through architecture to implementation tasks
 topics: [validation, traceability, requirements, coverage]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Traceability

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

@@ -2,6 +2,12 @@
 name: web-app-api-patterns
 description: REST API design for web clients, GraphQL client patterns, error handling strategies, request deduplication, auth injection, and CORS
 topics: [web-app, api, rest, graphql, cors, error-handling, auth]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.mozilla.org/en-US/docs/Web/HTTP
+  - url: https://spec.graphql.org/
 ---
 
 The API layer is the seam between frontend and backend. Poor design here manifests as waterfall requests that serialize page loads, inconsistent error shapes that require fragile client-side guessing, auth token handling bugs that cause random 401 errors, and CORS misconfigurations that block legitimate requests. A well-designed API client is boring: it handles auth transparently, errors consistently, and requests efficiently — so product engineers can focus on features rather than network plumbing.

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

@@ -2,6 +2,12 @@
 name: web-app-architecture
 description: Rendering strategy tradeoffs, CDN edge patterns, hydration strategies, BFF pattern, and micro-frontend considerations for web apps
 topics: [web-app, architecture, ssr, ssg, spa, hydration, bff, micro-frontends, cdn]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://martinfowler.com/articles/micro-frontends.html
+  - url: https://developer.mozilla.org/en-US/docs/Web/Performance
 ---
 
 Web application architecture is the set of decisions that are expensive to reverse: rendering strategy, client-server boundary, data fetching patterns, and infrastructure topology. These decisions must be made with explicit tradeoff acknowledgment and documented as Architecture Decision Records. The most common architectural mistake is choosing a sophisticated pattern because it is interesting, not because the problem demands it.

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

@@ -2,6 +2,15 @@
 name: web-app-auth-patterns
 description: OAuth 2.0 + PKCE flows, cookie security, passkey/WebAuthn, social login, CSRF protection, and auth state management
 topics: [web-app, auth, oauth, pkce, webauthn, passkeys, csrf, security]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://www.rfc-editor.org/rfc/rfc6749
+  - url: https://www.rfc-editor.org/rfc/rfc7636
+  - url: https://openid.net/specs/openid-connect-core-1_0.html
+  - url: https://www.w3.org/TR/webauthn-2/
+  - url: https://owasp.org/www-community/attacks/csrf
 ---
 
 Authentication in web applications is a deep domain where implementation mistakes have severe security consequences. The auth surface spans the browser, the server, and third-party identity providers — and each boundary has its own threat model. OAuth 2.0 with PKCE is now the standard for delegated authorization; WebAuthn/passkeys are rapidly becoming the standard for credential-free authentication; and session cookie security attributes are the baseline that every web app must get right. Skipping any of these correctly has historically led to breaches.

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

@@ -2,6 +2,11 @@
 name: web-app-conventions
 description: Component naming, file colocation, state management patterns, custom hook conventions, and CSS methodology selection for web apps
 topics: [web-app, conventions, components, state-management, css, hooks]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.mozilla.org/en-US/docs/Web/CSS
 ---
 
 Conventions are the difference between a codebase where any engineer can find and modify any file in minutes versus one where only the original author can navigate it confidently. Establish these once, enforce them via linting and code review, and never let individual preferences override them during the project lifecycle.

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

@@ -2,6 +2,12 @@
 name: web-app-data-patterns
 description: Client-side caching, optimistic updates, real-time sync, pagination strategies, form state management, and file upload patterns
 topics: [web-app, data-fetching, caching, react-query, swr, pagination, forms, file-upload]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
+  - url: https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
 ---
 
 Data management in web applications spans from simple fetch-and-display to complex real-time collaborative state. The wrong patterns here produce stale UIs, conflicting updates, degraded performance under load, and frustrated users. The right patterns make applications feel instantaneous even over slow networks — by understanding the difference between server state, client state, and ephemeral UI state, and applying the appropriate tool to each.

package/content/knowledge/web-app/web-app-deployment-workflow.md

@@ -2,6 +2,12 @@
 name: web-app-deployment-workflow
 description: Preview deploys per PR, staging environments, deployment branches, CI/CD pipeline stages, rollback strategies, and canary deployments
 topics: [web-app, deployment, ci-cd, staging, preview, rollback, canary]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://martinfowler.com/bliki/CanaryRelease.html
+  - url: https://sre.google/sre-book/release-engineering/
 ---
 
 A mature deployment workflow transforms deployment from a risky, manual event into a routine, automated step. The goal is to make every merge to main automatically and safely deliverable to production, with fast rollback when something goes wrong. The cost of building this infrastructure up front is trivially small compared to the cost of a major incident caused by a manual deploy process.

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

@@ -2,6 +2,12 @@
 name: web-app-deployment
 description: Static CDN hosting, serverless platforms, container deployments, edge runtimes, long-running servers, and blue-green deploy patterns for web apps
 topics: [web-app, deployment, vercel, netlify, aws, docker, cloudflare, serverless, containers]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html
+  - url: https://martinfowler.com/bliki/BlueGreenDeployment.html
 ---
 
 Deployment platform selection determines your app's operational cost, performance ceiling, and scaling characteristics. Each platform has a different cost model, latency profile, and runtime constraint. Choose based on your app's rendering strategy, traffic patterns, and team's operational expertise — not on what is fashionable.

package/content/knowledge/web-app/web-app-design-system.md

@@ -2,6 +2,12 @@
 name: web-app-design-system
 description: Responsive token systems, dark/light mode, component library patterns, and CSS methodology selection for web applications
 topics: [web-app, design-system, css, tokens, dark-mode, responsive]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://tr.designtokens.org/format/
+  - url: https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties
 ---
 
 A design system is the contract between design and engineering. Without one, components drift, spacing is inconsistent, and every engineer makes independent decisions about color, typography, and layout. A well-structured token system makes that contract explicit, machine-enforceable, and refactorable — changing a spacing scale or switching a brand color becomes a one-line edit rather than a codebase-wide search-and-replace.

package/content/knowledge/web-app/web-app-dev-environment.md

@@ -2,6 +2,12 @@
 name: web-app-dev-environment
 description: Dev server configuration, HMR setup, API proxy, environment variables, Docker for local services, and browser devtools for web app development
 topics: [web-app, dev-environment, vite, webpack, hmr, docker, debugging]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.chrome.com/docs/devtools
+  - url: https://developer.mozilla.org/en-US/docs/Tools
 ---
 
 A fast, reliable local development environment is a force multiplier for the entire team. The goal is sub-second feedback loops for code changes and zero friction getting from a fresh checkout to a running app. Every minute spent fighting the dev environment is a minute not spent building the product.

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

@@ -2,6 +2,12 @@
 name: web-app-observability
 description: Real User Monitoring, Core Web Vitals tracking, error tracking with Sentry, CDN analytics, custom performance marks, and performance regression alerting
 topics: [web-app, observability, rum, core-web-vitals, sentry, performance, monitoring]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://opentelemetry.io/docs/
+  - url: https://www.w3.org/TR/performance-timeline/
 ---
 
 You cannot improve what you cannot measure. Frontend observability is often treated as an afterthought — added after users start complaining — but by then you have no baseline to regress against and no historical data to understand when performance degraded or errors started. Real User Monitoring (RUM) captures the experience of your actual users on their actual devices and networks, which lab-based tests like Lighthouse cannot replicate. Core Web Vitals are Google's standardized metrics for page experience and directly influence search ranking.

package/content/knowledge/web-app/web-app-project-structure.md

@@ -2,6 +2,11 @@
 name: web-app-project-structure
 description: Directory layout conventions, route organization, shared vs feature modules, barrel exports, and config file placement for web apps
 topics: [web-app, project-structure, architecture, routing, modules]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://martinfowler.com/bliki/PresentationDomainDataLayering.html
 ---
 
 A well-structured web app project is navigable by any developer without a tour. The directory layout should communicate the architecture at a glance: where pages live, where shared code lives, where API logic lives, and where configuration lives. A poor structure forces every developer to ask "where does this go?" on every new file they create.

package/content/knowledge/web-app/web-app-rendering-strategies.md

@@ -2,6 +2,12 @@
 name: web-app-rendering-strategies
 description: SSR TTFB and SEO benefits, SSG for content sites, ISR, streaming SSR, React Server Components, and progressive hydration patterns
 topics: [web-app, rendering, ssr, ssg, isr, streaming, react-server-components, hydration]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.mozilla.org/en-US/docs/Glossary/SSR
+  - url: https://developer.mozilla.org/en-US/docs/Glossary/SPA
 ---
 
 Rendering strategy is the foundational technical decision in a web app — it determines server infrastructure requirements, SEO characteristics, performance profile, and the developer model for data fetching. Understanding the precise mechanics of each strategy (not just their marketing descriptions) is essential for making and defending the right choice for a given project.

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

@@ -2,6 +2,12 @@
 name: web-app-requirements
 description: SSR/SPA decision criteria, Core Web Vitals budgets, responsive breakpoints, browser support matrix, PWA considerations, and SEO requirements
 topics: [web-app, requirements, performance, pwa, seo, accessibility]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://www.w3.org/TR/WCAG22/
+  - url: https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps
 ---
 
 Defining web app requirements before writing a line of code prevents the most expensive rework in the project lifecycle. Rendering strategy, performance budgets, and browser support targets affect every architectural decision downstream. Locking these down early — with explicit tradeoff acknowledgment — removes ambiguity and gives the team a shared definition of "done."

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

@@ -2,6 +2,14 @@
 name: web-app-security
 description: XSS prevention, Content Security Policy, CSRF tokens, clickjacking, Subresource Integrity, dependency auditing, and OWASP top 10 for web apps
 topics: [web-app, security, xss, csp, csrf, clickjacking, owasp, dependency-auditing]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://owasp.org/www-project-top-ten/
+  - url: https://www.w3.org/TR/CSP3/
+  - url: https://owasp.org/www-community/attacks/xss/
+  - url: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
 ---
 
 Web application security failures are among the most costly and common causes of data breaches. The OWASP Top 10 has catalogued the same categories of vulnerabilities for decades — not because they are new, but because they recur in every generation of frameworks and technologies. Understanding the attack vectors and their mitigations is not optional for engineers building user-facing web applications. Security must be designed in, not bolted on.

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

@@ -2,6 +2,13 @@
 name: web-app-session-patterns
 description: Session management architecture, JWT vs cookie sessions, refresh token rotation, session storage, and hijacking prevention
 topics: [web-app, auth, sessions, jwt, cookies, security, redis]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://owasp.org/www-project-cheat-sheets/cheatsheets/Session_Management_Cheat_Sheet.html
+  - url: https://www.rfc-editor.org/rfc/rfc7519
+  - url: https://www.rfc-editor.org/rfc/rfc6265
 ---
 
 Session management is the mechanism by which a web application recognizes a returning user between HTTP requests. Because HTTP is stateless, sessions are an application-level construct — and the design decisions here directly affect security, scalability, and user experience. The wrong session architecture causes token theft, session fixation attacks, memory exhaustion on the server, and logout failures that leave users permanently authenticated even after they believe they've signed out.

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

@@ -2,6 +2,12 @@
 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]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://www.w3.org/WAI/standards-guidelines/aria/
+  - url: https://developer.chrome.com/docs/lighthouse/overview
 ---
 
 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).

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

@@ -2,6 +2,12 @@
 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]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://www.w3.org/TR/WCAG22/
+  - url: https://developer.mozilla.org/en-US/docs/Web/Accessibility
 ---
 
 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.

package/content/knowledge/web3/web3-access-control.md

@@ -2,6 +2,14 @@
 name: web3-access-control
 description: Role-based access control for smart contracts — Ownable2Step, OpenZeppelin AccessControl, Safe multisig as admin, TimelockController on dangerous ops, role separation, and decentralization via renouncing
 topics: [web3, access-control, openzeppelin, multisig, timelock]
+volatility: fast-moving
+last-reviewed: null
+version-pin: 'OpenZeppelin Contracts 5.x'
+sources:
+  - url: https://docs.openzeppelin.com/contracts/5.x/access-control
+    anchor: '#access-control'
+  - url: https://docs.safe.global/home/what-is-safe
+    anchor: '#safe-multisig'
 ---
 
 Most contract exploits are not novel cryptography — they are either missing access-control checks ("anyone can call `setFeeRecipient`") or a single admin key getting drained, phished, or coerced. Access control is the answer to three questions: who can change what, when can they change it, and whose consent is required to authorize the change. A protocol whose answer is "the deployer EOA, immediately, alone" is a protocol one phishing email away from a post-mortem. Production-grade access control replaces each of those answers with a deliberate engineering choice: granular roles, time-locked execution windows, and multi-party signing.

package/content/knowledge/web3/web3-architecture.md

@@ -2,6 +2,13 @@
 name: web3-architecture
 description: EVM smart-contract architecture decisions — modular vs monolithic decomposition, OpenZeppelin baseline, state minimization, library vs inheritance, diamond pattern caveats, and external-call discipline
 topics: [web3, architecture, solidity, evm, openzeppelin]
+volatility: evolving
+last-reviewed: null
+version-pin: 'OpenZeppelin Contracts 5.x; Solidity 0.8.x'
+sources:
+  - url: https://docs.openzeppelin.com/contracts/5.x/
+  - url: https://ethereum.org/en/developers/docs/smart-contracts/
+  - url: https://consensys.github.io/smart-contract-best-practices/
 ---
 
 This overlay targets **EVM** chains — Ethereum mainnet, the major L2s (Arbitrum, Optimism, Base, zkSync, Polygon zkEVM), and other EVM-compatible execution layers running Solidity 0.8.x bytecode. Non-EVM ecosystems (Solana / Anchor, Aptos and Sui / Move, Cosmos / CosmWasm) have fundamentally different storage, account, and execution models and are deliberately out of scope here; a future W3-2 overlay may cover dApp / frontend work and non-EVM runtimes. Architecture in this doc means the contract-side decisions a protocol lead makes before the first `forge build`: how to decompose, what to inherit, how state is laid out, and where the trust boundaries fall.

package/content/knowledge/web3/web3-audit-workflow.md

@@ -2,6 +2,13 @@
 name: web3-audit-workflow
 description: Pre-audit readiness, tooling (Slither, Echidna, Halmos, Certora), CI integration, firm selection, timing, remediation, and post-launch bug bounties for protocol teams preparing for a smart-contract audit
 topics: [web3, audit, slither, echidna, halmos, security]
+volatility: fast-moving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://consensys.github.io/smart-contract-best-practices/
+  - url: https://swcregistry.io/
+  - url: https://docs.openzeppelin.com/contracts/5.x/
 ---
 
 Audits are expensive ($30k–$500k+) and time-consuming, and the meter starts the day the auditors open your repo — not the day they find their first bug. A team that hands over a half-finished spec, 40% test coverage, and a Slither report full of unaddressed mediums is paying senior security engineers to do the work the team should have done before kickoff. The protocols that get the most out of an audit treat the engagement as a final review against work already proven correct, not as a substitute for it. Maximize value by being ready before the audit starts.