contextos-agents 2.3.0 → 2.3.2

package/.agents/core/skills/gstack-roles/references/roles.md

@@ -1,149 +1,5 @@
+# gstack-roles compatibility reference
 
-# gstack-roles
+Canonical guidance: [engineering-workflow](../../engineering-workflow/SKILL.md).
 
-## Overview
-
-Specialist persona orchestrator defining 23 domain roles (Product Manager, Architect, Senior Developer, QA Lead, Chief Security Officer, etc.). Enforces mindset transitions across engineering pipeline phases.
-
-## When to Use
-
-Activate on every task to declare explicit specialist role and mindset before beginning DEFINE, PLAN, BUILD, VERIFY, REVIEW, or SHIP phases.
-
-## Rules & Patterns
-
-Inspired by [Garry Tan's gstack](https://github.com/garrytan/gstack) - structured persona transitions across engineering phases.
-
-## Core Principle
-
-> Before starting ANY task, identify your current role. You are not a generic AI. You are a specialist. Think and act accordingly.
-
-## Role Identification Protocol
-
-At the start of each task or major phase switch, declare your role using the ContextOS standard format:
-
-```text
-[DOMAIN: <Domain>] [PHASE: <Phase>] [ROLE: <Role Name>]
-Skills loaded: <skill-1>, <skill-2>
-```
-
-> **Anti-Spam Invariant**: Declare this role header **strictly once per phase**. Never prefix intermediate tool calls, file operations, or step updates with role tags.
-
-Then execute ONLY within the constraints of that role.
-
----
-
-## The 23 Specialist Roles
-
-### Strategy & Planning
-
-| Role | Mandate | When to Activate |
-| ------ | --------- | ----------------- |
-| **CEO / Founder** | Rethink the problem. Find the 10-star product hiding inside the request. Challenge scope. | Feature planning, product decisions |
-| **YC Office Hours** | Ask 6 forcing questions that reframe the product before writing code. Push back on framing. | Before any new feature starts |
-| **Product Manager** | Define requirements as user stories. Prioritize ruthlessly. Ship the narrowest wedge first. | Requirement gathering |
-| **Architect** | Lock in architecture, data flow, diagrams, edge cases. Force hidden assumptions into the open. | System design, tech stack decisions |
-
-### Engineering
-
-| Role | Mandate | When to Activate |
-| ------ | --------- | ----------------- |
-| **Engineering Manager** | Break work into atomic tasks. Review test plans. Run retrospectives. | Sprint planning, reviews |
-| **Staff Engineer** | Find bugs that pass CI but blow up in production. Auto-fix the obvious. Flag gaps. | Code review |
-| **Senior Developer** | Write production-quality code. Follow architecture decisions. Test everything. | Implementation |
-| **Debugger** | Systematic root-cause debugging. Iron Law: no fixes without investigation. | Bug fixing |
-| **Performance Engineer** | Baseline metrics. Core Web Vitals. Resource sizes. Compare before/after. | Optimization |
-| **Developer Experience Lead** | Benchmark onboarding speed. Find friction. Design the magical moment. | DX review |
-
-### Design
-
-| Role | Mandate | When to Activate |
-| ------ | --------- | ----------------- |
-| **Senior Designer** | Rate each design dimension 0-10. Detect AI slop. Interactive: one question per design choice. | Design review, UI tasks |
-| **Design Engineer** | Turn mockups into production HTML/CSS that actually works. 30KB, zero deps where possible. | Frontend implementation |
-| **Design Explorer** | Generate 4-6 design variants. Open comparison. Iterate until user loves it. | Design ideation |
-
-### Quality & Security
-
-| Role | Mandate | When to Activate |
-| ------ | --------- | ----------------- |
-| **QA Lead** | Test the app, find bugs, fix with atomic commits, re-verify, write regression tests. | Before shipping |
-| **QA Reporter** | Pure bug report only. No code changes. | Bug reporting |
-| **Chief Security Officer** | OWASP Top 10 + STRIDE threat model. Zero-noise: 8/10+ confidence gate. Each finding needs exploit scenario. | Security audit |
-
-### Operations & Release
-
-| Role | Mandate | When to Activate |
-| ------ | --------- | ----------------- |
-| **Release Engineer** | Sync main, run tests, audit coverage, push, open PR. Bootstrap test frameworks if missing. | Before shipping |
-| **SRE** | Post-deploy monitoring loop. Watch for console errors, performance regressions, failures. | After deploy |
-| **Technical Writer** | Update all docs to match what shipped. Catch stale READMEs. Build Diataxis coverage map. | After feature ships |
-
-### Research & Memory
-
-| Role | Mandate | When to Activate |
-| ------ | --------- | ----------------- |
-| **Researcher** | Investigate root causes systematically. No fixes without understanding. Max 3 hypothesis cycles. | Unknown problems |
-| **Memory Manager** | Manage learnings across sessions. Review, search, prune, export project patterns. | Session start/end |
-| **Spec Author** | Turn vague intent into precise executable specs in 5 phases: why, scope, technical, draft, file. | Before planning |
-| **Retro Facilitator** | Per-person breakdowns, shipping streaks, test health trends, growth opportunities. | End of sprint |
-
----
-
-## Sprint Lifecycle
-
-Every change follows this lifecycle, with a specific role per phase:
-
-```
-THINK          PLAN           BUILD          REVIEW         TEST           SHIP
-[YC Hours]   [Architect]   [Sr Developer]  [Staff Eng]   [QA Lead]    [Release Eng]
-[CEO]        [Eng Mgr]                     [Designer]    [Sec Officer]
-```
-
-## Role-Switching Rules
-
-1. **Use proportional phases.** Scope substantial work; routine edits can proceed directly.
-2. **One role at a time.** Don't mix QA and implementation in the same response.
-3. **Declare when helpful.** Role labels are optional communication aids.
-4. **Escalate correctly.** If a QA finds an architectural problem → escalate to Architect role.
-5. **The CEO always goes last on planning** - challenges scope reduction before committing.
-
-## Example Usage
-
-```
-User: "Add a notifications feature"
-
-[ROLE: YC Office Hours]
-Before I plan this, 6 forcing questions:
-1. What pain does the ABSENCE of notifications cause today?
-2. Who specifically gets notified? What's the trigger?
-...
-
-[ROLE: CEO / Founder]
-I'm going to push back on "notifications feature."
-What you actually described is a user re-engagement system.
-The narrowest wedge: one email on task completion.
-Ship that tomorrow. The full vision is a 3-month project.
-
-[ROLE: Architect]
-For the narrow wedge:
-- Event: task.completed → webhook → email queue (Redis)
-- No real-time needed for MVP
-- Schema: notifications(id, user_id, type, payload, sent_at)
-```
-
-
-## Code Examples
-
-See `EXAMPLES.md` for detailed code examples.
-
-## Validation Checklist
-
-What to verify during the review phase before completing the task.
-
-## Common Mistakes
-
-Anti-patterns and things to explicitly avoid. See `TROUBLESHOOTING.md`.
-
-## Integration Notes
-
-How this skill interacts with other skills.
+Useful review perspectives are product scope, architecture, implementation, QA, security, and release. Choose only those relevant to the inspected change. Role declarations are optional, and switching roles within one model is self-review. Ask for missing material decisions instead of a fixed six-question interview.

package/.agents/core/skills/ponytail-mindset/EXAMPLES.md

@@ -1,45 +1,12 @@
-# ponytail-mindset Examples — Anti-patterns vs ContextOS Standard
-
-## Example 1: Data Formatting and Manipulation
-
-### Anti-pattern: Over-engineered Custom Utility Class
-
-```typescript
-// BAD: 40 lines of boilerplate for relative date formatting
-export class DateFormatterService {
-  private static instance: DateFormatterService;
-  public static getInstance() { /* singleton boilerplate */ }
-  public formatRelative(date: Date): string {
-    const diff = Date.now() - date.getTime();
-    // 30 lines of manual math, plurals, and string building
-  }
-}
-```
-
-### Best practice: ContextOS Standard (Standard Library Native API)
-
-```typescript
-// GOOD: Native Intl API, zero bundle cost, handles all locales
-export const formatRelativeTime = (date: Date, locale = 'en'): string => {
-  const diffDays = Math.round((date.getTime() - Date.now()) / (1000 * 60 * 60 * 24));
-  return new Intl.RelativeTimeFormat(locale, { numeric: 'auto' }).format(diffDays, 'day');
-};
-```
-
----
-
-## Example 2: Component Library Reuse
-
-### Anti-pattern: Hand-rolled Modal from Scratch
-
-```text
-BAD: Writing custom overlay DOM, manual scroll locking, manual focus trapping,
-and custom keydown listeners. Burns 300+ lines of fragile code.
-```
-
-### Best practice: ContextOS Standard (Leverage Established Primitives)
-
-```bash
-# GOOD: Install battle-tested primitive that handles ARIA, portals, and keyboard navigation
-npx shadcn@latest add dialog
-```
+# Minimalism examples
+
+- Formatting: use Intl.DateTimeFormat, Intl.RelativeTimeFormat, or the existing
+  formatter after verifying locale, timezone, invalid-date, and rounding needs.
+  A snippet's length is not a measured bundle or accuracy guarantee.
+- UI: reuse the installed component library when it meets accessibility and
+  interaction requirements. Use a native control when it meets those requirements.
+- Protected writes: see the executable updater in
+  [references/minimalism.md](references/minimalism.md). Copying arbitrary payload
+  fields into persistence does not satisfy minimalism or security.
+- Refactoring: a small named function can be clearer than repeated inline logic,
+  even before its third use.

package/.agents/core/skills/ponytail-mindset/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ponytail-mindset
-description: Choose a minimal maintainable implementation for substantive Build tasks while preserving safety and verification.
+description: "Choose a minimal maintainable implementation for substantive Build tasks while preserving safety and verification."
 ---
 
 # ponytail-mindset
@@ -11,31 +11,28 @@ Reduce unnecessary code and dependencies without weakening correctness or securi
 
 ## When to Use
 
-Substantive implementation and refactoring during Build.
+Substantive implementation, refactoring, and reviews of complexity.
 
 ## Rules & Patterns
 
-Before adding code, check whether the feature is needed and whether existing code, the standard library, the platform, or an installed dependency handles it. Then implement the smallest readable solution. Avoid premature abstractions. Preserve validation, authorization, parameterized queries, meaningful error handling, and required tests.
+Before adding code, consider YAGNI, project reuse, the standard library, native platform features, installed dependencies, a readable one-liner, then the minimum maintainable code. Preserve validation, authorization, parameterized queries, meaningful errors, and required checks. Single-use helpers are allowed when they clarify a concept or boundary.
 
-The 7-rung ladder: YAGNI; reuse project code; standard library; native platform;
-installed dependencies; a readable one-liner; the minimum maintainable code.
-
-Read [references/minimalism.md](references/minimalism.md) for detailed procedures and examples only when needed.
+Read [references/minimalism.md](references/minimalism.md) when a tradeoff needs detail.
 
 ## Code Examples
 
-Reuse the existing date formatter. A shorter database query still needs authorization and validated input.
+Reuse the installed date formatter. An update endpoint still validates its payload and checks ownership before writing.
 
 ## Validation Checklist
 
-- [ ] The requested outcome is handled.
-- [ ] Relevant verification and safety boundaries are preserved.
-- [ ] Limitations are stated.
+- [ ] The requested outcome and applicable failure cases are checked.
+- [ ] Evidence names commands, results, scope, and limitations.
+- [ ] Unrelated changes and existing authorization are preserved.
 
 ## Common Mistakes
 
-Repeated approval after authorization; unnecessary ceremonies for routine edits; treating role labels or string checks as behavioral proof.
+Code-golf; deleting safety checks; choosing a new component library by default; duplicating access-control logic solely to obey a reuse count.
 
 ## Integration Notes
 
-Load relevant domain skills and supporting resources on demand. Compatibility identifiers remain available.
+engineering-workflow chooses verification by risk; security defines protected boundaries. This skill chooses implementation size and readability.

package/.agents/core/skills/ponytail-mindset/TROUBLESHOOTING.md

@@ -1,19 +1,10 @@
-# ponytail-mindset Troubleshooting & Common Mistakes
-
-## 1. Conflating Minimalism with Cutting Safety Guards
-
-- **Symptom**: Agent removes input validation, error handling, or security checks in the name of "less code".
-- **Root Cause**: Misunderstanding the Ponytail principle. Ponytail cuts unnecessary abstractions, never safety invariants.
-- **Fix**: Invariant: Always retain 100% of input sanitization, error boundaries, and type safety checks.
-
-## 2. "Just In Case" Speculative Coding (YAGNI Violation)
-
-- **Symptom**: Adding config options, generics, and plugin interfaces for features not requested.
-- **Root Cause**: Premature future-proofing.
-- **Fix**: Apply Rung 1 of the ladder: If it doesn't solve the immediate requirement, do not write it.
-
-## 3. Reinventing Installed Dependencies
-
-- **Symptom**: Writing a deep-clone helper when Lodash or native structuredClone is available.
-- **Root Cause**: Skipping inspection of package.json and runtime environment.
-- **Fix**: Inspect installed dependencies before writing utility functions.
+# Minimalism troubleshooting
+
+- A shorter patch removes validation: restore the boundary checks before comparing
+  implementation sizes.
+- A helper is used once: evaluate its meaning, isolation, and readability rather
+  than automatically inlining it.
+- A new dependency appears: inspect the existing stack and actual requirement.
+- Retry behavior is assumed: check the SDK contract and test failure handling.
+- A code example is illustrative: do not report a running integration until the
+  real imports, persistence, authentication, and checks have been supplied.

package/.agents/core/skills/ponytail-mindset/VALIDATION.json

@@ -1,12 +1,123 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
+  "x-contextos-evidence-contract": 1,
+  "title": "Scoped verification evidence",
+  "description": "Report shape and outcome consistency only; command execution and agent behavior require separate evidence.",
   "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "status",
+    "checks",
+    "limitations"
+  ],
   "properties": {
-    "rules_followed": {
-      "type": "boolean"
+    "status": {
+      "enum": [
+        "verified",
+        "partial",
+        "not_run"
+      ]
+    },
+    "checks": {
+      "type": "array",
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": [
+          "command",
+          "exitCode",
+          "scope"
+        ],
+        "properties": {
+          "command": {
+            "type": "string",
+            "minLength": 1
+          },
+          "exitCode": {
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "scope": {
+            "type": "string",
+            "minLength": 1
+          }
+        }
+      }
+    },
+    "limitations": {
+      "type": "array",
+      "items": {
+        "type": "string",
+        "minLength": 1
+      }
     }
   },
-  "required": [
-    "rules_followed"
+  "allOf": [
+    {
+      "if": {
+        "properties": {
+          "status": {
+            "const": "verified"
+          }
+        }
+      },
+      "then": {
+        "properties": {
+          "checks": {
+            "minItems": 1,
+            "items": {
+              "properties": {
+                "exitCode": {
+                  "const": 0
+                }
+              }
+            }
+          }
+        }
+      }
+    },
+    {
+      "if": {
+        "properties": {
+          "status": {
+            "enum": [
+              "partial",
+              "not_run"
+            ]
+          }
+        }
+      },
+      "then": {
+        "properties": {
+          "limitations": {
+            "minItems": 1
+          }
+        }
+      }
+    },
+    {
+      "if": {
+        "properties": {
+          "status": {
+            "const": "not_run"
+          }
+        }
+      },
+      "then": {
+        "properties": {
+          "checks": {
+            "items": {
+              "properties": {
+                "exitCode": {
+                  "type": "null"
+                }
+              }
+            }
+          }
+        }
+      }
+    }
   ]
 }

package/.agents/core/skills/ponytail-mindset/references/minimalism.md

@@ -1,186 +1,70 @@
+# Minimal maintainable implementation
 
-# ponytail-mindset
+## Decision ladder
 
-## Overview
+1. Does this solve the requested outcome? Avoid speculative features.
+2. Does project code or the installed component system already handle it?
+3. Does the standard library provide the operation?
+4. Does the native platform meet the actual requirements?
+5. Can an installed dependency handle it without extra integration cost?
+6. Can it be a readable one-liner without hiding boundary checks?
+7. Otherwise write the smallest clear implementation.
 
-Minimalist engineering discipline that eliminates over-engineering and premature abstraction while maintaining 100% of required validation, type safety, error boundaries, and security invariants.
+The rule of three is a duplication heuristic, not a ban on named functions.
+Extract a single-use helper when it clarifies an invariant or isolates an I/O
+boundary. Prefer the project's established UI system; do not install shadcn or
+another library merely because a generic guide names it. dayjs is a dependency,
+not a standard-library API. Verify retry/circuit-breaker support in the actual
+SDK; do not assume native fetch supplies an application retry policy.
 
-## When to Use
+## Preserve boundary validation
 
-Activate on all BUILD phases to prevent bloated implementations and enforce concise, focused solutions.
-
-## Rules & Patterns
-
-Based on [DietrichGebert/ponytail](https://github.com/DietrichGebert/ponytail).
-
-> _He says nothing. He writes one line. It works._
-
-**Core Impact**: Dramatically reduces code footprint by eliminating premature abstraction, YAGNI violations, and boilerplate, while keeping all safety invariants (validation, error handling, security) 100% intact.
-
----
-
-### Core Principle
-
-> **The best code is code you don't write.**\
-> Write only what the task strictly needs. Lazy about the solution, never about reading and understanding.
-
----
-
-### The 7-Rung Decision Ladder
-
-**Before writing ANY code**, stop and check each rung in order. Stop at the first rung that holds:
-
-```text
-1. Does this need to exist?
-   → No: YAGNI — skip it entirely. Don't build for "future use."
-
-2. Already in this codebase or component library?
-   → Yes: Reuse it. Don't rewrite. Call the existing function/component/module.
-   → For UI: Check shadcn/ui FIRST. Before building a complex UI element from scratch, check if it exists in the component library. If yes, generate the install command: npx shadcn@latest add dialog — never manually rewrite what shadcn already provides.
-
-3. Standard library does it?
-   → Yes: Use it. Don't write formatDate() — use Intl.DateTimeFormat or dayjs.
-
-4. Native platform feature?
-   → Yes: Use it. Don't install flatpickr when <input type="date"> exists.
-   → Exception for UI Components: If a native HTML element (like <input type="date"> or <select>) CANNOT be styled consistently across Chrome, Safari, and Firefox to match the premium design system — use the established component library (e.g., shadcn/ui <DatePicker>, <Select>) instead. Cross-browser inconsistency is a legitimate reason to NOT use native.
-
-5. Already-installed dependency?
-   → Yes: Use it. Don't install a new library to do what an existing one can.
-
-6. Can it be done in one line?
-   → Yes: One line. No abstraction layer needed.
-
-7. Only then: write the MINIMUM that works.
-   → No classes when a function works. No module when an inline does.
-```
-
----
-
-### The Rule of Three (Do Not Abstract Early)
-
-- **First occurrence**: Write it inline directly where it is needed.
-- **Second occurrence**: Duplicate it cleanly. Duplication is cheaper than the wrong abstraction.
-- **Third occurrence**: Only now extract a shared helper or utility.
-
----
-
-### 10 Concrete Over-Engineering Red Flags
-
-1. Creating a `GenericRepository<T>` when you only have 2 database tables.
-2. Creating a custom state machine or complex reducer for 2 boolean flags.
-3. Adding a configuration file or environment variables for values that never change.
-4. Writing custom retry/circuit-breaker logic when native `fetch` or SDK already handles it.
-5. Building a generic `BaseService` with 15 hook methods implemented by only one class.
-6. Wrapping every standard library call in a custom helper class (`StringUtils`, `DateUtils`, `ObjectUtils`).
-7. Creating a multi-level folder structure (`domains/auth/adapters/driving/rest/controllers/dto/`) for a 30-line microservice.
-8. Writing custom mock frameworks when Vitest/Jest/Node test runner provide standard mocks.
-9. Installing a 50KB npm package for a 3-line utility (e.g. `left-pad`, `is-number`, `deep-clone`).
-10. Pre-optimizing caching and indexing for endpoints serving 10 requests a day.
-
----
-
-### The Sacred Exceptions (NEVER Cut These)
-
-The ladder applies to features and abstractions. These 4 areas are **non-negotiable** and **never simplified away**:
-
-#### 1. Input Validation
+This runnable example defines a protected update operation around a supplied
+persistence function. The caller must obtain the session through trusted
+server-side authentication. The sample schema covers only name/email; adapt it
+to the real product schema, error contracts, and tenant model.
 
+<!-- example: ponytail-update -->
 ```javascript
-// [GOOD] Always validate — even if "internal" API
-function createUser(data) {
-  if (!data.email || !isValidEmail(data.email)) {
-    throw new ValidationError('Invalid email');
-  }
-  return db.insert('users', data);
-}
-
-// [BAD] Never skip validation for "speed"
-function createUser(data) {
-  return db.insert('users', data); // NEVER
+export function createUserUpdater(update) {
+  if (typeof update !== 'function') throw new TypeError('Persistence function required');
+  return async function updateUser(id, data, session) {
+    if (typeof id !== 'string' || !id || session?.userId !== id) {
+      throw new Error('Forbidden');
+    }
+    if (!data || typeof data !== 'object' || Array.isArray(data)) {
+      throw new TypeError('Invalid update payload');
+    }
+    const keys = Object.keys(data);
+    if (!keys.length || keys.some(key => !['name', 'email'].includes(key))) {
+      throw new TypeError('Unknown or empty update fields');
+    }
+    const parsed = {};
+    if (Object.hasOwn(data, 'name')) {
+      if (typeof data.name !== 'string' || !data.name.trim() || data.name.length > 100) {
+        throw new TypeError('Invalid name');
+      }
+      parsed.name = data.name;
+    }
+    if (Object.hasOwn(data, 'email')) {
+      if (typeof data.email !== 'string' || data.email.length > 254 ||
+          !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(data.email)) {
+        throw new TypeError('Invalid email');
+      }
+      parsed.email = data.email;
+    }
+    return update({ where: { id }, data: parsed });
+  };
 }
 ```
 
-#### 2. Error Handling
-
-```javascript
-// [GOOD] Always handle errors explicitly
-async function fetchUser(id) {
-  try {
-    const user = await db.findById(id);
-    if (!user) throw new NotFoundError(`User ${id} not found`);
-    return user;
-  } catch (err) {
-    logger.error('fetchUser failed', { id, err });
-    throw err;
-  }
-}
-```
-
-#### 3. Security Checks
-
-- Authorization check BEFORE every query or mutation.
-- Parameterized queries everywhere — zero string concatenation in SQL.
-- Strict sanitization of all rendered HTML and markdown.
-
-#### 4. Type Safety & Behavioral Tests
-
-- Strict TypeScript types — no `any` evasion.
-- Tests covering happy path, 4xx, and 5xx edge cases.
-
----
-
-## Code Examples
-
-### Native Platform vs Over-Built Package
-
-**Over-build**:
-
-```bash
-npm install flatpickr
-# Creates DatePickerWrapper.jsx (45 lines) + useDatePicker.js (30 lines) + styles (60 lines)
-```
-
-**Ponytail approach (rung 4)**:
-
-```html
-<input type="date" name="date" aria-label="Appointment date" />
-```
-
-### Next.js App Router Server Action vs REST Endpoint
-
-```typescript
-// Instead of /api/users/[id]/route.ts + custom fetch wrapper:
-"use server";
-
-export async function updateUser(id: string, data: UpdateUserInput) {
-  const session = await getSession(); // auth check — never skip
-  if (session?.userId !== id) throw new Error("Forbidden");
-  return db.users.update(id, data);
-}
-```
-
----
-
-## Validation Checklist
-
-- [ ] Every new dependency has been verified: cannot be solved with native platform or existing dependencies.
-- [ ] No single-use abstractions, wrappers, or interfaces created.
-- [ ] Sacred exceptions preserved: 100% input validation, explicit error handling, security checks intact.
-- [ ] All code written passes all existing unit and integration tests.
-
----
-
-## Common Mistakes
-
-- **Cutting validation to write less code**: The goal is less architecture/boilerplate, never less safety.
-- **Creating utilities "for future use"**: Only write utilities when used 3+ times.
-- **Rewriting component libraries**: Building custom modals, tabs, or tooltips from scratch when shadcn/ui or Radix is already in the project.
-
----
+The verifier runs this block with an injected persistence function and asserts
+that denied users, invalid emails, and unknown privilege fields never reach it.
+This is boundary evidence, not proof of a live database or authentication setup.
 
-## Integration Notes
+## Verification checklist
 
-- Applies during substantive Build work and reviews of implementation complexity.
-- Enforces minimalism alongside `system-design` (think at scale, implement minimally).
-- Pairs with `impeccable-design` for UI tasks.
+- Each dependency or abstraction solves an inspected requirement.
+- Protected inputs and operations retain their checks.
+- Errors have a meaningful contract; avoid redundant catch/log/rethrow layers.
+- Behavior checks cover relevant success and failure cases.