valent-pipeline 0.2.20 → 0.2.21

package/pipeline/steps/qa-b/library.md

@@ -0,0 +1,61 @@
+# QA-B Step: Library Testing
+
+## Library Consumer Tests
+
+Mandatory for all stories with library/package exports. Install the library in an isolated environment and test it as a real consumer would.
+
+**Procedure:**
+
+1. **Create isolated temp directory.** Initialize a fresh project with the appropriate package manager. This must be outside the library source tree.
+2. **Install the library.** Use a local path install (`npm install ../path-to-lib`, `pip install -e ../path-to-lib`, etc.) to simulate a real consumer installation.
+3. **Execute CJS import tests.** For each export in the Export Smoke Test table, `require()` the module path and verify the expected export is present and has the correct type/signature. Record PASS/FAIL.
+4. **Execute ESM import tests.** For each export in the Export Smoke Test table, `import` the module path and verify the expected export is present and has the correct type/signature. Record PASS/FAIL.
+5. **Execute API contract tests.** Call each exported function/class with the documented usage example. Verify return values match declared types and documented behavior.
+6. **Measure bundle size.** If applicable, bundle the library with a standard bundler (esbuild, webpack, rollup) and record the output size. Flag if significantly larger than expected.
+7. **Verify tree-shaking.** If `sideEffects: false` is declared, bundle a selective import and verify unused exports are excluded from the output.
+8. **Clean up temp directory.**
+
+**Record results** in `## Library Consumer Test Results` of execution-report.md:
+
+```
+## Export Audit Results
+
+| Export Name | CJS require() | ESM import | Type Declaration | Contract Test | Result |
+|-------------|---------------|------------|-----------------|---------------|--------|
+| {name} | {PASS/FAIL} | {PASS/FAIL} | {PASS/FAIL} | {PASS/FAIL} | {overall} |
+
+## CJS/ESM Interop
+
+| Test | Result | Notes |
+|------|--------|-------|
+| CJS require() resolves | {PASS/FAIL} | {details} |
+| ESM import resolves | {PASS/FAIL} | {details} |
+| Named exports match | {PASS/FAIL} | {details} |
+| Default export consistent | {PASS/FAIL} | {details} |
+| No dual-instance corruption | {PASS/FAIL} | {details} |
+
+## Bundle Size
+
+| Entry Point | Raw Size | Minified | Gzipped | Notes |
+|-------------|----------|----------|---------|-------|
+| {entry} | {bytes} | {bytes} | {bytes} | {flags if oversized} |
+```
+
+Include raw commands and full output for reproducibility.
+
+**Failure handling:**
+- Install fails: file P1 bug, record error, continue.
+- CJS/ESM import fails: file bug at appropriate priority, continue remaining tests.
+- Type declarations missing: file P2 bug, continue.
+- Bundle size exceeds threshold: file P3 bug as advisory.
+
+**This step cannot be skipped.** If qa-test-spec.md lacks an Export Smoke Tests section, construct the table from exports in reqs-brief.md and execute.
+
+## Execution Report Additions
+
+The execution report MUST include:
+- `## Export Audit Results` table with PASS/FAIL for each export and import method
+- `## CJS/ESM Interop` table with detailed interop verification
+- `## Bundle Size` table with measured sizes
+- Raw install, import, and bundle commands with full output
+- Isolated temp directory path and cleanup confirmation

package/pipeline/steps/qa-b/mcp-server.md

@@ -0,0 +1,40 @@
+# QA-B Step: MCP Server Testing
+
+## Protocol Compliance Tests
+
+Mandatory for all stories with MCP server tools. Spawn a real server and communicate over the actual transport.
+
+**Procedure:**
+
+1. **Spawn server.** Start the MCP server process with the configured transport (stdio/SSE/HTTP). For stdio, connect to stdin/stdout pipes. For SSE/HTTP, poll the endpoint (max 10 retries, 1s apart) until the server accepts connections.
+2. **JSON-RPC initialize.** Send `initialize` request. Verify server info (name, version) and capability declarations match expected values from qa-test-spec.md.
+3. **tools/list.** Send `tools/list` request. Verify all expected tools are present with correct names, descriptions, and inputSchema.
+4. **tools/call per tool.** For each tool in the protocol smoke test table, send `tools/call` with the specified params. Capture the result. Compare content types, result shape, and values against expected.
+5. **Error paths.** Execute error path rows from the smoke test table:
+   - Unknown tool: send `tools/call` with a non-existent tool name. Verify JSON-RPC error response.
+   - Bad params: send `tools/call` with params violating the declared inputSchema. Verify `-32602` error code.
+   - Tool failure: trigger a tool-level error. Verify `isError: true` in the result.
+   - Malformed JSON: send raw invalid JSON over the transport. Verify `-32700` error code.
+6. **Stop server.**
+7. **Record results** in `## Protocol Compliance Results` of execution-report.md:
+
+```
+| ID | JSON-RPC Method | Params | Expected Result | Actual Result | Expected Error Code | Actual Error Code | Result |
+```
+
+Include raw JSON-RPC request/response pairs for reproducibility.
+
+**Failure handling:**
+- Server fails to start: file P1 bug, record error, continue.
+- Protocol test fails: file bug at appropriate priority, continue remaining tests.
+- Server crashes mid-test: file P1 bug, record crash output, attempt restart.
+
+**This step cannot be skipped.** If qa-test-spec.md lacks a Protocol Smoke Tests section, construct the table from tools in reqs-brief.md and execute.
+
+## Execution Report Additions
+
+The execution report MUST include:
+- `## Protocol Compliance Results` table with actual vs expected for every row
+- Raw JSON-RPC request/response pairs
+- Server startup command and output
+- Transport type and connection confirmation

package/pipeline/steps/qa-b/mobile-app.md

@@ -0,0 +1,71 @@
+# QA-B Step: Mobile App Testing
+
+## Pre-Execution: Verify Mobile Infrastructure
+
+Before running Maestro flows:
+
+1. **Emulator check:** Verify `adb devices` shows at least one connected emulator/device in `device` state (not `offline` or `unauthorized`)
+2. **If no emulator:** Follow boot procedure from MOBILE's emulator-lifecycle step. If boot fails after retries, file P1 bug: "Android emulator failed to boot. Cannot execute Maestro flows."
+3. **App installed check:** `adb shell pm list packages | grep {app_package}`. If app not listed, build and install per MOBILE procedure. If install fails, file P1 bug.
+4. **iOS check (Mac only):** Verify `xcrun simctl list devices | grep Booted` shows at least one booted simulator. If iOS flows exist but no simulator is booted, boot one. If not on Mac, iOS flows are deferred (not a bug).
+5. **API server check (if story calls APIs):** Send health check to API server. If unreachable, start via `docker compose up -d db api` or project-equivalent. If still unreachable, file P1 bug.
+
+## Maestro Flow Execution
+
+For each Maestro flow from qa-test-spec.md:
+1. **State isolation:** `adb shell pm clear {app_package}` (Android) / `xcrun simctl terminate + privacy reset` (iOS)
+2. **Pre-grant permissions:** per flow's permission requirements
+3. **Execute:** `maestro test {flow_file}` (Android) or `maestro test {flow_file} --device {simulator}` (iOS)
+4. **Capture evidence:** Maestro test output + any `takeScreenshot` captures
+5. **Record result:** pass/fail with output details
+
+## Post-Execution: Platform Coverage Audit
+
+After all Maestro flows execute, audit platform coverage:
+
+### Step 1: Scan Flow Results by Platform
+
+| Flow File | Android Result | iOS Result | Both Required |
+|-----------|---------------|------------|---------------|
+| {flow} | {PASS \| FAIL} | {PASS \| FAIL \| DEFERRED} | {yes \| no} |
+
+### Step 2: Check for Deferred iOS Tests
+
+If host is not Mac:
+- All iOS-only and `both` flows that could not run on iOS are deferred
+- This is expected — NOT a bug
+- Record in execution report as "iOS deferred — host OS limitation"
+
+### Step 3: File Bugs
+
+- **Android failures are always bugs** — Android emulator is always available
+- **iOS failures on Mac are bugs** — if the simulator was available and a flow failed, that is a real failure
+- **iOS inability on Windows/Linux is deferred, not a bug** — record as deferred with platform reason
+
+### Step 4: Mock Coverage (N/A for Maestro)
+
+Maestro flows inherently hit the real app and real API server — there is no API interception mechanism. Unlike Playwright `route.fulfill()`, Maestro cannot mock API responses. This means mock coverage audit is not applicable for Maestro E2E flows. However, verify:
+- The app is configured to hit the real API server (check base URL in build config / environment)
+- Actual network traffic is flowing (check `adb shell dumpsys netstats uid {app_uid}` for non-zero bytes)
+- If all API calls show zero bytes, file P1 bug: "App appears to use hardcoded/cached data — no real API traffic detected"
+
+## Execution Report Additions
+
+The execution report MUST include:
+
+```
+## Mobile Platform Coverage Audit
+
+- Host platform: {Mac | Windows | Linux}
+- Android emulator: {PASS — booted | FAIL — details}
+- iOS simulator: {PASS — booted | N/A — not Mac | FAIL — details}
+- Total Maestro flows: {count}
+- Android flows executed: {count} / passed: {count} / failed: {count}
+- iOS flows executed: {count} / passed: {count} / deferred: {count}
+- Platform coverage: {FULL | PARTIAL-IOS-DEFERRED}
+- API traffic verified: {yes | no | N/A — no API calls}
+```
+
+## Quality Gate: This Step Cannot Be Skipped
+
+If `testing_profiles` includes `mobile-app`, this audit is mandatory. The mobile platform coverage audit must appear in the execution report.

package/pipeline/steps/readiness/standalone-review.md

@@ -10,6 +10,10 @@ Read the story's ACs and scope. Independently assess which `testing_profiles` sh
 - `api` — story has API endpoints, backend logic, or database changes
 - `ui` — story has UI components, pages, or visual elements
 - `data-pipeline` — story has ETL, data transformation, or batch processing
+- `mcp-server` — story has MCP server tools, handlers, or protocol work
+- `library` — story is shared library/package (exports, packaging, versioning)
+- `document-generation` — story has document/report template or generation pipeline work
+- `iac` — story has infrastructure work (Terraform, CloudFormation, Kubernetes, CI/CD)
 
 Compare your assessment against the `testing_profiles` tagged on the backlog entry:
 - **Missing profile that should be present** → reject to Lead: `[READINESS-REJECTION] Story {story_id}: testing_profiles missing '{profile}'. Re-tag and re-groom.` **STOP.**
@@ -42,8 +46,9 @@ Read `{story_output_dir}/reqs-brief.md`. Record in `inputsRead`.
 | Pre-mortem addressed | Findings folded-in or accepted-risk with justification |
 | Required sections populated | All template sections present and non-empty (or N/A with rationale) |
 | Business rules complete | Cover all ACs with edge case notes |
-| Database changes specified | Present or explicitly "none" with rationale |
-| API endpoints specified | Present or explicitly "none" with rationale |
+| Database changes specified | Present or explicitly "none" with rationale (only check if api or data-pipeline in testing_profiles) |
+| API endpoints specified | Present or explicitly "none" with rationale (only check if api in testing_profiles) |
+| Domain-specific sections | Conditional sections populated per active testing_profiles (e.g., Tool Definitions for mcp-server, Public API Surface for library) |
 | Cross-cutting concerns | Error handling, validation, auth defined |
 
 **If ANY fails:** Reject to `readiness-review.md#reqs-rejection-reasons`. Send `[READINESS-REJECTION]` to **REQS** AND to Lead: `[READINESS-REJECTION] Story {story_id}: ACs need rework. See readiness-review.md#reqs-rejection-reasons.` **STOP**.

package/pipeline/steps/reqs/data-pipeline.md

@@ -0,0 +1,56 @@
+# REQS Step: Data Pipeline Requirements
+
+## Step 4b: Data-Pipeline-Specific Requirement Extraction
+
+For stories with `data-pipeline` in `testing_profiles`, extract additional requirements:
+
+### Source and Destination Definitions
+- Data format per source/destination (CSV, JSON, Parquet, database table, API response)
+- Schema definition (column names, types, nullable, constraints)
+- Location and access method (file path, connection string, API endpoint, bucket)
+- Volume expectations (row counts, file sizes, batch frequency)
+
+### Transform Specifications
+- Business rules per transform stage (filtering criteria, aggregation logic, joins)
+- Computation definitions (derived fields, formulas, lookups)
+- Stage ordering and dependencies (which transforms must precede others)
+- Data type coercions and casting rules
+
+### Data Quality Rules
+- Null handling per field (reject, default, propagate, coalesce)
+- Deduplication strategy (natural keys, window, first/last wins)
+- Referential integrity checks (foreign key validation, orphan handling)
+- Row count expectations per stage (exact, range, ratio)
+- Value range and format validation (regex, min/max, enum membership)
+
+### Idempotency Strategy
+- Natural keys or surrogate keys for upsert behavior
+- Upsert vs insert-only vs replace semantics per destination
+- Rerun safety guarantees (running the same input twice produces identical output)
+- Timestamp or version column handling on reruns
+
+### Checkpoint and Resume Design
+- State persistence mechanism (file marker, database row, offset tracking)
+- Checkpoint granularity (per-batch, per-file, per-row, per-stage)
+- Recovery behavior on restart (replay from last checkpoint, skip completed)
+- Partial output cleanup on failure (rollback, leave partial, quarantine)
+
+### Error Handling per Stage
+- Per-stage error strategy: skip row, fail batch, quarantine row, log and continue
+- Quarantine destination and format (dead-letter table, error file, log)
+- Error threshold before batch abort (count or percentage)
+- Alerting and notification requirements on failure
+
+### Schema Evolution Strategy
+- How added columns are handled (ignore, default, fail)
+- How removed columns are handled (ignore, fail, null-fill)
+- How type changes are handled (coerce, fail, flag)
+- Schema version tracking and compatibility policy
+
+## Quality Gate Additions
+
+- [ ] Every AC involving data movement has malformed-input behavior defined
+- [ ] Every source and destination has format, schema, and location specified
+- [ ] Idempotency strategy defined for every write stage
+- [ ] Error handling strategy specified per pipeline stage
+- [ ] Null handling defined for every nullable field

package/pipeline/steps/reqs/document-generation.md

@@ -0,0 +1,55 @@
+# REQS Step: Document Generation Requirements
+
+## Step 4b: Document-Generation-Specific Requirement Extraction
+
+For stories with `document-generation` in `testing_profiles`, extract additional requirements:
+
+### Template Definitions
+- Which templates exist and what each produces
+- Template format and engine (Handlebars, Jinja, EJS, custom)
+- Template inheritance or composition (partials, layouts, includes)
+- Template versioning and selection logic
+
+### Variable Schema per Template
+- Required variables with types and validation rules
+- Optional variables with default values
+- Null/missing variable behavior per field (blank, placeholder text, omit section, error)
+- Variable nesting (objects, arrays, conditionals within variable data)
+
+### Output Format Requirements
+- Output format(s): PDF, HTML, Markdown, DOCX, other
+- MIME type for each output format
+- Page layout specifications (margins, orientation, page size) for paginated formats
+- Styling requirements (CSS, embedded styles, theme)
+
+### Conditional Section Rules
+- Include/exclude logic per section (which variables or conditions control visibility)
+- Empty collection handling (show "no items" message vs hide section entirely)
+- Mutual exclusion rules (sections that cannot appear together)
+- Ordering rules for dynamic sections
+
+### Encoding Requirements
+- Character encoding: UTF-8 handling and validation
+- Unicode support (emoji, CJK, diacritics)
+- RTL language support (if applicable)
+- Special character escaping per output format (HTML entities, PDF text encoding)
+
+### Asset Dependencies
+- Fonts: which fonts, embedded or referenced, fallback chain
+- Images and logos: source location, embedded or referenced, format (PNG, SVG, base64)
+- Stylesheets: external or inline, caching behavior
+- Asset resolution strategy (relative paths, CDN, bundled)
+
+### Large Document Handling
+- Streaming or chunked generation for large outputs
+- Maximum document size or page count limits
+- Memory constraints and timeout behavior
+- Progress reporting for long-running generation
+
+## Quality Gate Additions
+
+- [ ] Every template variable has defined null/missing behavior
+- [ ] Every template has output format and MIME type specified
+- [ ] Conditional section logic documented with include/exclude rules
+- [ ] Asset dependencies listed with embedding vs reference strategy
+- [ ] Encoding requirements specified for non-ASCII content

package/pipeline/steps/reqs/draft-brief.md

@@ -25,3 +25,13 @@ Assign priority based on business impact, complexity, and novelty:
 | P1 | Feature broken, degraded UX | Medium | Moderate | CRUD operations with business rules, form validation |
 | P2 | Minor inconvenience | Low | Familiar | Display formatting, sort order, pagination |
 | P3 | Cosmetic, nice-to-have | Trivial | Standard | Label text, tooltip content, logging |
+
+### Profile-Aware Section Selection
+
+Populate template sections based on active `{testing_profiles}`:
+- **Database Changes**: include if `api` or `data-pipeline` in profiles. Skip entirely for other profiles.
+- **API Endpoints**: include if `api` in profiles. Skip entirely for other profiles.
+- **Authentication and Authorization**: include if `api` or `ui` in profiles. Skip entirely for other profiles.
+- **Domain-specific sections**: include the conditional sections from `reqs-brief.template.md` that match active profiles (Data Pipeline Specification, Tool Definitions, Public API Surface, Template Specifications, Infrastructure Resources).
+
+For multi-profile stories (e.g., `[api, iac]`), include ALL applicable sections.

package/pipeline/steps/reqs/iac.md

@@ -0,0 +1,63 @@
+# REQS Step: Infrastructure Requirements
+
+## Step 4b: IaC-Specific Requirement Extraction
+
+For stories with `iac` in `testing_profiles`, extract additional requirements:
+
+### Resource Inventory
+- What resources are created, modified, or destroyed (with provider and resource type)
+- Purpose of each resource (why it exists, what depends on it)
+- Resource dependencies and creation order
+- Naming convention per resource (prefix, environment, region, random suffix)
+
+### Tagging Policy
+- Required tags per resource (environment, project, owner, cost-center, managed-by)
+- Tag naming conventions and allowed values
+- Tags that must propagate to child resources
+- Tag enforcement mechanism (policy, validation, linting)
+
+### IAM Requirements
+- Roles and policies per resource (what identity, what permissions, on what scope)
+- Least-privilege justification (why each permission is needed)
+- Service account or managed identity requirements
+- Cross-account or cross-subscription access (if applicable)
+- Temporary credential strategy (assume role, workload identity federation)
+
+### State Management
+- Remote backend configuration (storage account, bucket, table)
+- State locking mechanism and timeout
+- State access control (who can read/write state)
+- State file segmentation (per-environment, per-module, monolith)
+
+### Environment Topology
+- Environments: dev, staging, prod (and any others)
+- Differences between environments (instance sizes, replica counts, feature flags)
+- Environment promotion strategy (apply same config with different vars)
+- Shared vs isolated resources across environments
+
+### Compliance Constraints
+- Encryption requirements: at rest (which resources, key management) and in transit (TLS version)
+- Network isolation: VPC/VNet, subnets, security groups, private endpoints
+- Audit logging: which resources, log destination, retention period
+- Data residency: region constraints, data sovereignty requirements
+- Regulatory framework alignment (SOC2, HIPAA, GDPR -- if applicable)
+
+### Destroy Protection
+- Which resources must never be accidentally destroyed (databases, storage, DNS)
+- Safeguards per protected resource (lifecycle prevent_destroy, deletion locks, backups)
+- Manual approval gates before destructive changes
+- Backup and recovery requirements before destroy is permitted
+
+### Drift Detection
+- Detection method: scheduled plan, continuous monitoring, cloud-native service
+- Alerting on drift detection (who is notified, channel, severity)
+- Auto-remediation policy (auto-apply, alert-only, manual review)
+- Expected drift sources (manual console changes, other automation)
+
+## Quality Gate Additions
+
+- [ ] Every resource has tagging and destroy-protection policy defined
+- [ ] IAM permissions follow least-privilege with justification
+- [ ] State management backend and locking strategy specified
+- [ ] Environment topology differences documented
+- [ ] Encryption and network isolation requirements specified per resource

package/pipeline/steps/reqs/library.md

@@ -0,0 +1,56 @@
+# REQS Step: Library Requirements
+
+## Step 4b: Library-Specific Requirement Extraction
+
+For stories with `library` in `testing_profiles`, extract additional requirements:
+
+### Public API Surface
+- Exported symbols (functions, classes, constants, types)
+- Function signatures with parameter types and return types
+- Overload variants (if applicable)
+- Re-export paths (subpath exports via package.json `exports` map)
+
+### Semver Policy
+- What constitutes a breaking change (removed export, changed signature, changed behavior)
+- What constitutes a minor change (new export, new optional parameter)
+- What constitutes a patch change (bug fix, internal refactor, docs)
+- Current version and expected version after this story ships
+
+### Backwards Compatibility Constraints
+- Previously published API surface that must remain stable
+- Deprecated symbols and their migration path
+- Minimum supported runtime versions (Node.js, browser targets)
+- Compatibility with existing consumer code patterns
+
+### Module System Requirements
+- Package format: CJS, ESM, or dual
+- Entry points: `main`, `module`, `exports` map configuration
+- Conditional exports (node, import, require, default)
+- Build output structure and file extensions (.js, .mjs, .cjs)
+
+### Type Declaration Requirements
+- Type declaration strategy: `.d.ts` files, inline TypeScript, JSDoc
+- Generic type parameters and constraints
+- Strict mode compatibility (noImplicitAny, strictNullChecks)
+- Type export completeness (every public symbol has a corresponding type)
+
+### Peer Dependency Contract
+- Required peer dependencies with version ranges
+- Optional peer dependencies and behavior when absent
+- Conflict resolution for overlapping dependency ranges
+- Runtime detection of missing peers (clear error messages)
+
+### Tree-Shaking Requirements
+- `sideEffects` field value (false, or list of side-effectful files)
+- Barrel re-export avoidance (no index files that re-export everything)
+- Per-export isolation (importing one symbol must not pull in unrelated code)
+- Bundle size expectations for selective imports
+
+## Quality Gate Additions
+
+- [ ] Every exported symbol has defined behavior and type
+- [ ] Semver impact classified (breaking, minor, or patch)
+- [ ] Module system entry points specified (CJS, ESM, or dual)
+- [ ] Type declarations defined for every public export
+- [ ] Peer dependency contract documented with version ranges
+- [ ] Tree-shaking requirements specified if sideEffects: false is declared

package/pipeline/steps/reqs/mcp-server.md

@@ -0,0 +1,48 @@
+# REQS Step: MCP Server Requirements
+
+## Step 4b: MCP-Server-Specific Requirement Extraction
+
+For stories with `mcp-server` in `testing_profiles`, extract additional requirements:
+
+### Tool Definitions
+- Tool name, human-readable description, and purpose
+- Which tools the server exposes at `tools/list`
+- Tool grouping or categorization (if server exposes many tools)
+
+### Input Schemas per Tool
+- Required and optional parameters with types
+- Parameter constraints (min/max, regex, enum values, string length)
+- Nested object schemas and array item types
+- Default values for optional parameters
+
+### Output Content Types per Tool
+- Content type per tool response (text, image, audio, resource)
+- Response shape: key fields, MIME types, encoding
+- Multi-content responses (tools returning mixed content types)
+- Resource URIs and their resolution behavior
+
+### Capability Declarations
+- What the server advertises in `initialize` response (tools, resources, prompts)
+- Server info (name, version)
+- Protocol version compatibility
+- Resource subscription support (if applicable)
+
+### Transport Requirements
+- Supported transport(s): stdio, SSE, streamable HTTP
+- Connection lifecycle (startup, shutdown, reconnect behavior)
+- Concurrency model (serial tool calls vs parallel)
+- Timeout behavior per tool (long-running operations, cancellation)
+
+### Error Model per Tool
+- JSON-RPC error codes for protocol-level failures (-32700, -32600, -32601, -32602, -32603)
+- `isError: true` content responses for tool-level failures (business logic errors)
+- Specific error scenarios per tool (invalid input, resource not found, permission denied, rate limited)
+- Error message format and detail level
+
+## Quality Gate Additions
+
+- [ ] Every tool has explicit error behavior defined (both JSON-RPC codes and isError:true scenarios)
+- [ ] Every tool has an input schema with required/optional params and types
+- [ ] Every tool has output content type(s) specified
+- [ ] Capability declarations documented for initialize handshake
+- [ ] Transport requirements specified

package/pipeline/steps/reqs/mobile-app.md

@@ -0,0 +1,54 @@
+# REQS Step: Mobile App Requirements
+
+## Step 4b: Mobile-App-Specific Requirement Extraction
+
+For stories with `mobile-app` in `testing_profiles`, extract additional requirements:
+
+### Screen Inventory
+- Screen names and navigation hierarchy (stack, tab, drawer, modal)
+- Deep link URI patterns per screen (e.g., `myapp://settings/profile`)
+- Back button / gesture behavior per screen (Android hardware back, iOS swipe-to-go-back)
+- Screen transition animations (if specified in UX)
+
+### Platform-Specific Behavior
+- Android-only vs iOS-only vs shared behavior per AC
+- Permission requirements per platform (camera, location, notifications, storage, contacts, biometrics)
+- Minimum OS version targets (Android API level, iOS version)
+- Platform-specific UI patterns (Material Design vs Human Interface Guidelines)
+
+### Offline and Connectivity Requirements
+- Offline-capable features and sync behavior (queue-and-retry, optimistic UI, conflict resolution)
+- Network error handling per screen (retry, fallback, offline banner)
+- Local storage / caching strategy (AsyncStorage, MMKV, SQLite, Hive)
+- Background sync requirements
+
+### Device Form Factor
+- Phone vs tablet layout requirements
+- Orientation support (portrait, landscape, both) per screen
+- Safe area / notch / dynamic island handling
+- Keyboard avoidance behavior for input screens
+
+### Push Notification Requirements
+- Notification types and payload structure
+- Foreground vs background handling behavior
+- Deep link from notification tap (target screen, parameters)
+- Silent / data-only notification handling
+
+### App Lifecycle Requirements
+- Background → foreground behavior (refresh data, re-authenticate)
+- App termination recovery (restore navigation state, pending form data)
+- Multi-window / split-screen behavior (if applicable)
+
+### Native Module Dependencies
+- Camera, biometrics, file system, Bluetooth, NFC, etc.
+- Third-party SDK requirements (maps, analytics, crash reporting)
+- Platform-specific native module availability
+
+## Quality Gate Additions
+
+- [ ] Every screen has navigation path and deep link documented
+- [ ] Platform-specific behavior explicit for each AC (or explicitly marked "identical on both platforms")
+- [ ] Permission requirements listed per platform
+- [ ] Offline behavior specified (or explicitly marked as online-only)
+- [ ] Push notification handling defined (or explicitly marked as no-push)
+- [ ] App lifecycle edge cases addressed (background/foreground, termination recovery)

package/pipeline/steps/reqs/self-review.md

@@ -10,13 +10,15 @@ Verify completeness:
 - [ ] Every AC has a priority classification (P0-P3)
 - [ ] All ambiguities are documented with resolution and rationale
 - [ ] Business rules cover all ACs with edge case notes
-- [ ] Database changes are specified (or explicitly marked "none" with rationale)
-- [ ] API endpoints are specified (or explicitly marked "none" with rationale)
-- [ ] Auth requirements are defined
+- [ ] If api or data-pipeline in testing_profiles: database changes are specified (or explicitly marked "none" with rationale)
+- [ ] If api in testing_profiles: API endpoints are specified (or explicitly marked "none" with rationale)
+- [ ] If api or ui in testing_profiles: auth requirements are defined
 - [ ] Cross-cutting concerns are addressed
 - [ ] NFR targets are set
 - [ ] Pre-mortem has at least 3 findings
 - [ ] All pre-mortem `folded-in` findings are reflected in the brief
 - [ ] Cross-references section points to all consumed inputs
+- [ ] All quality gate additions from loaded domain step files (Step 4b) are satisfied
+- [ ] Domain-specific conditional sections from template are populated for each active profile
 
 If any check fails, go back and fix it before proceeding.

package/pipeline/task-graphs/backend-api.yaml

@@ -37,12 +37,20 @@ tasks:
     activeForm: "BEND implementing backend"
     blockedBy: [readiness]
 
+  - ref: iac
+    agent: IAC
+    subject: "IAC: Implement infrastructure definitions and tests"
+    description: "Read reqs-brief.md and qa-test-spec.md, implement infrastructure code, produce iac-handoff.md."
+    activeForm: "IAC implementing infrastructure"
+    blockedBy: [readiness]
+    conditional: "testing_profiles includes iac"
+
   - ref: critic
     agent: CRITIC
     subject: "CRITIC: Adversarial code review"
     description: "Read git-diff, reqs-brief.md, qa-test-spec.md. Run blind-hunt, edge-case-hunt, acceptance-audit, triage passes. Produce critic-review.md."
     activeForm: "CRITIC reviewing code"
-    blockedBy: [bend]
+    blockedBy: [bend, iac]
 
   - ref: qa_b
     agent: QA-B
@@ -102,12 +110,21 @@ agents:
     completion: "Send [HANDOFF] to Lead and CRITIC. Mark task completed."
     cd_targets: [bend]
 
+  - name: IAC
+    ref: iac
+    wave: 2
+    spawn_trigger: "qa_a completed"
+    prompt: .valent-pipeline/prompts/iac.md
+    trigger: "Begin immediately — you were spawned because QA-A completed. Wait for READINESS approval before starting implementation."
+    completion: "Send [HANDOFF] to Lead and CRITIC. Mark task completed."
+    cd_targets: [iac]
+
   - name: CRITIC
     ref: critic
     wave: 2
     spawn_trigger: "qa_a completed"
     prompt: .valent-pipeline/prompts/critic.md
-    trigger: "Begin immediately — you were spawned because QA-A completed. Wait for [HANDOFF] from BEND before starting review."
+    trigger: "Begin immediately — you were spawned because QA-A completed. Wait for [HANDOFF] from all active dev agents before starting review."
     completion: "Send [HANDOFF] to Lead and QA-B. Mark task completed."
     cd_targets: [critic]