takt 0.35.4 → 0.36.0

package/builtins/en/facets/knowledge/takt.md

@@ -2,34 +2,34 @@
 
 ## Core Structure
 
-PieceEngine is a state machine. It manages movement transitions via EventEmitter.
+WorkflowEngine is a state machine. It manages step transitions via EventEmitter.
 
 ```
-CLI → PieceEngine → Runner (4 types) → RuleEvaluator → next movement
+CLI → WorkflowEngine → Runner (4 types) → RuleEvaluator → next step
 ```
 
 | Runner | Purpose | When to Use |
 |--------|---------|-------------|
-| MovementExecutor | Standard 3-phase execution | Default |
-| ParallelRunner | Concurrent sub-movements | parallel block |
+| StepExecutor | Standard 3-phase execution | Default |
+| ParallelRunner | Concurrent sub-steps | parallel block |
 | ArpeggioRunner | Data-driven batch processing | arpeggio block |
 | TeamLeaderRunner | Task decomposition → parallel sub-agents | team_leader block |
 
-Runners are mutually exclusive. Do not specify multiple runner types on a single movement.
+Runners are mutually exclusive. Do not specify multiple runner types on a single step.
 
 ### 3-Phase Execution Model
 
-Normal movements execute in up to 3 phases. Sessions persist across phases.
+Normal steps execute in up to 3 phases. Sessions persist across phases.
 
 | Phase | Purpose | Tools | Condition |
 |-------|---------|-------|-----------|
-| Phase 1 | Main work | Movement's allowed_tools | Always |
+| Phase 1 | Main work | Step's allowed_tools | Always |
 | Phase 2 | Report output | Write only | When output_contracts defined |
 | Phase 3 | Status judgment | None (judgment only) | When tag-based rules exist |
 
 ## Rule Evaluation
 
-RuleEvaluator determines the next movement via 5-stage fallback. Earlier match takes priority.
+RuleEvaluator determines the next step via 5-stage fallback. Earlier match takes priority.
 
 | Priority | Method | Target |
 |----------|--------|--------|
@@ -49,7 +49,7 @@ When multiple tags appear in output, the **last match** wins.
 | `all("...")` / `any("...")` | Aggregate condition | `AGGREGATE_CONDITION_REGEX` |
 | Plain string | Tag or AI fallback | — |
 
-Adding new special syntax requires updating both pieceParser.ts regex and RuleEvaluator.
+Adding new special syntax requires updating both workflowParser.ts regex and RuleEvaluator.
 
 ## Provider Integration
 
@@ -72,7 +72,7 @@ ProviderAgent.call(prompt, options) → AgentResponse
 Models resolve through 5-level priority. Higher takes precedence.
 
 1. persona_providers model specification
-2. Movement model field
+2. Step model field
 3. CLI `--model` override
 4. config.yaml (when resolved provider matches)
 5. Provider default
@@ -104,8 +104,8 @@ Uses vitest. Test file naming conventions distinguish test types.
 | Prefix | Type | Content |
 |--------|------|---------|
 | None | Unit test | Individual function/class verification |
-| `it-` | Integration test | Piece execution simulation |
-| `engine-` | Engine test | PieceEngine scenario verification |
+| `it-` | Integration test | Workflow execution simulation |
+| `engine-` | Engine test | WorkflowEngine scenario verification |
 
 ### Mock Provider
 

package/builtins/en/facets/output-contracts/architecture-review.md

@@ -36,6 +36,11 @@ Scope: "In-scope" (fixable in this change) / "Out-of-scope" (existing issue, non
 |---|------------|------------|--------------------------|---------------------|-------|----------------|
 | 1 | ARCH-REOPENED-src-file-L55 | design-violation | `Previously fixed at src/file.ts:10` | `Recurred at src/file.ts:55` | Issue description | Fix approach |
 
+## Verification Evidence
+- Build: {Verified target, what was checked, and observed result; or state that it was unverified}
+- Tests: {Verified target, what was checked, and observed result; or state that it was unverified}
+- Functional check: {Verified target, what was checked, and observed result; or state that it was unverified}
+
 ## Rejection Gate
 - REJECT is valid only when at least one finding exists in `new`, `persists`, or `reopened`
 - Findings without `finding_id` are invalid

package/builtins/en/facets/output-contracts/qa-review.md

@@ -35,6 +35,11 @@
 |---|------------|------------|--------------------------|---------------------|-------|----------------|
 | 1 | QA-REOPENED-src-test-L55 | test-coverage | `Previously fixed at src/test.ts:10` | `Recurred at src/test.ts:55` | Issue description | Fix approach |
 
+## Verification Evidence
+- Build: {Verified target, what was checked, and observed result; or state that it was unverified}
+- Tests: {Verified target, what was checked, and observed result; or state that it was unverified}
+- Functional check: {Verified target, what was checked, and observed result; or state that it was unverified}
+
 ## Rejection Gate
 - REJECT is valid only when at least one finding exists in `new`, `persists`, or `reopened`
 - Findings without `finding_id` are invalid

package/builtins/en/facets/output-contracts/requirements-review.md

@@ -41,6 +41,11 @@
 |---|------------|------------|--------------------------|---------------------|-------|----------------|
 | 1 | REQ-REOPENED-src-file-L55 | req-gap | `Previously fixed at file:line` | `Recurred at file:line` | Issue description | Fix approach |
 
+## Verification Evidence
+- Build: {Verified target, what was checked, and observed result; or state that it was unverified}
+- Tests: {Verified target, what was checked, and observed result; or state that it was unverified}
+- Functional check: {Verified target, what was checked, and observed result; or state that it was unverified}
+
 ## Rejection Gate
 - REJECT is valid only when at least one finding exists in `new`, `persists`, or `reopened`
 - Findings without `finding_id` are invalid

package/builtins/en/facets/output-contracts/security-review.md

@@ -33,6 +33,11 @@
 |---|------------|------------|--------------------------|---------------------|-------|----------------|
 | 1 | SEC-REOPENED-src-auth-L55 | injection-risk | `Previously fixed at src/auth.ts:20` | `Recurred at src/auth.ts:55` | Issue description | Fix approach |
 
+## Verification Evidence
+- Build: {Verified target, what was checked, and observed result; or state that it was unverified}
+- Tests: {Verified target, what was checked, and observed result; or state that it was unverified}
+- Functional check: {Verified target, what was checked, and observed result; or state that it was unverified}
+
 ## Warnings (non-blocking)
 - {Security recommendations}
 

package/builtins/en/facets/output-contracts/testing-review.md

@@ -37,6 +37,11 @@
 |---|------------|------------|--------------------------|---------------------|-------|----------------|
 | 1 | TEST-REOPENED-src-test-L55 | test-structure | `Previously fixed at src/test.ts:10` | `Recurred at src/test.ts:55` | Issue description | Fix approach |
 
+## Verification Evidence
+- Build: {Verified target, what was checked, and observed result; or state that it was unverified}
+- Tests: {Verified target, what was checked, and observed result; or state that it was unverified}
+- Functional check: {Verified target, what was checked, and observed result; or state that it was unverified}
+
 ## Rejection Gate
 - REJECT is valid only when at least one finding exists in `new`, `persists`, or `reopened`
 - Findings without `finding_id` are invalid

package/builtins/en/facets/personas/research-analyzer.md

@@ -42,4 +42,4 @@ When gaps are identified, evaluate on three points:
 
 - Is this gap important to the original request? (Ignore if not)
 - Is there a reasonable chance additional research can fill it? (Is public data likely available?)
-- Is the research cost (movement consumption) worthwhile?
+- Is the research cost (step consumption) worthwhile?

package/builtins/en/facets/personas/supervisor.md

@@ -26,10 +26,13 @@ you verify "**was the right thing built (Validation)**".
 - Mark missing execution evidence as unverified instead of assuming success
 - Treat contradictions between report text and execution evidence as first-class findings
 - Distinguish `false_positive` from `overreach`; a technically invalid finding and a scope-exceeding finding are not the same
+- Treat unversioned reports as the latest result and timestamped reports as history
+- Prefer reports with execution results or concrete verification details over summary-only reports
+- If a later report re-evaluates an earlier finding, adopt that re-evaluation only after checking it against the task, plan, and code
 
 ## Human-in-the-Loop Checkpoint
 
-You are the **human proxy** in the automated piece. Before approval, verify the following.
+You are the **human proxy** in the automated workflow. Before approval, verify the following.
 
 **Ask yourself what a human reviewer would check:**
 - Does this really solve the user's problem?

package/builtins/en/facets/policies/ai-antipattern.md

@@ -153,6 +153,21 @@ Legacy support criteria:
 - Do not add `.transform()` normalization, `LEGACY_*_MAP` mappings, or `@deprecated` type definitions
 - Support only new values and keep it simple
 
+## Premature Caching Strategy Introduction
+
+AI tends to proactively introduce caching mechanisms to "improve" performance. Do not add caching strategies until explicitly requested.
+
+| Pattern | Example | Verdict |
+|---------|---------|---------|
+| Adding cache layer to data fetching | stale-while-revalidate config, in-memory cache, Redis introduction | REJECT |
+| Saving cache locally | Storing API responses in local storage or files for reuse | REJECT |
+| Memoization without measurement | Excessive memoization without identifying bottlenecks | REJECT |
+| Custom cache invalidation implementation | Adding TTL, cache key management, purge mechanisms | REJECT |
+
+Decision criteria: Is there an explicit request or measurement result indicating "caching is needed"?
+- YES → OK to implement
+- NO → Do not implement. Naive data fetching is sufficient
+
 ## Dead Code Detection
 
 AI adds new code but often forgets to remove code that is no longer needed.

package/builtins/en/facets/policies/design-planning.md

@@ -49,4 +49,4 @@ Do not split out design-referenced elements as "another task" without explicit r
 
 - **Planning with only coarse screen-level summaries** - causes missing element coverage
 - **Narrowing the intent of the reference without rationale** - misaligns implementation and review
-- **Omitting the explanation for out-of-scope elements** - makes later movements ambiguous
+- **Omitting the explanation for out-of-scope elements** - makes later steps ambiguous

package/builtins/en/facets/policies/screen-api.md

@@ -0,0 +1,109 @@
+# Screen-Specific API Policy
+
+Provide data through screen-specific API endpoints. Do not assemble screens by repurposing generic APIs.
+
+## Principles
+
+| Principle | Criteria |
+|-----------|----------|
+| Screen-API alignment | Provide dedicated endpoints matching each screen's data needs |
+| Separate list and detail | Do not reuse list API responses for detail screens |
+| Aggregation via aggregation API | Do not fetch all records to count/summarize on the client |
+| Server owns pagination | Server manages page size, sort order, and filter conditions |
+| Add API when missing | Add a backend endpoint rather than working around it on the frontend |
+
+## Screen-Level API Design
+
+Design endpoints based on "what does this screen display and what does it operate on."
+
+| Pattern | Judgment | Reason |
+|---------|----------|--------|
+| List screen uses list API, detail screen uses detail API | OK | Screen and API responsibilities align |
+| Detail screen calls list API and searches result by ID | REJECT | Fetches unnecessary data, API contract mismatch |
+| Fetch all records to aggregate on the frontend for a decision | REJECT | Provide an aggregation API on the server |
+| Fetch both processing and completed from same API, filter on frontend | REJECT | Server should return them separately |
+| Screen needs data not available from existing APIs | Add an API | Do not combine other APIs as a workaround |
+
+```typescript
+// REJECT - Reusing list API for detail screen
+async function loadDetail(id: string) {
+  const list = await fetchList({ date })
+  return list.items.find(item => item.id === id)
+}
+
+// OK - Detail screen uses detail API
+async function loadDetail(id: string) {
+  return await fetchDetail(id)
+}
+```
+
+## Pagination and Data Volume Control
+
+Pagination responsibility belongs to the server. Frontend does not specify page size; server returns an appropriate number.
+
+| Pattern | Judgment |
+|---------|----------|
+| Server has default page size, frontend sends only nextId | OK |
+| Frontend specifies limit and sends it to server | Avoid (can't change server-side only) |
+| List API returns all records without limit | REJECT |
+| Server validates limit upper bound | OK |
+
+```typescript
+// Avoid - Frontend decides page size
+const result = await fetchList({ date, limit: 10, nextId })
+
+// OK - Frontend sends only nextId, server decides page size
+const result = await fetchList({ date, nextId })
+```
+
+## Aggregation and Decision Responsibility
+
+Decisions like "how many exist," "can generate," "should regenerate" are computed by the server and returned as results.
+
+| Pattern | Judgment |
+|---------|----------|
+| Fetch all records to determine batch generation eligibility | REJECT |
+| Aggregation API returns confirmed/unconfirmed counts | OK |
+| Server computes and returns canRegenerate flag | OK |
+| Frontend compares generated memo IDs to determine regeneration eligibility | REJECT |
+
+```typescript
+// REJECT - Fetch all for decision-making
+const memos = await fetchAllMemos({ date })
+const canGenerate = memos.filter(m => m.confirmed).length > 0
+
+// OK - Server returns aggregation
+const counts = await fetchMemoCounts({ date })
+// counts: { childId, memoCount, confirmedCount, unconfirmedCount }
+```
+
+## Tab/Screen Navigation and Communication Scope
+
+Communication is scoped to the active tab/screen. Do not prefetch for other tabs.
+
+| Pattern | Judgment |
+|---------|----------|
+| Only the visible tab communicates on tab switch | OK |
+| Parent component fetches for all tabs and distributes to children | REJECT |
+| Periodic polling runs only on the visible screen | OK |
+| Polling continues on hidden tabs | REJECT |
+
+## Backend Responsibilities
+
+Backend provides the following so that frontend can use screen-specific APIs.
+
+| Responsibility | Content |
+|---------------|---------|
+| Separate list and detail | List returns lightweight summaries, detail includes full information |
+| Embed related data | Include related data the screen needs in the response (avoid N+1) |
+| Aggregation endpoints | Return counts, confirmation status via dedicated endpoints |
+| Decision flags | Server computes can-regenerate, can-generate flags |
+| Pagination infrastructure | nextId cursor, default page size, limit validation |
+
+## Prohibited
+
+- **Generic API reuse** - Do not use list APIs for detail screens or fetch-all for aggregation
+- **Frontend-side aggregation** - Do not fetch all records to count on the client
+- **Cross-tab communication** - Do not prefetch data for other tabs
+- **Frontend page size specification** - Let the server decide
+- **Frontend workaround for missing API** - Add a dedicated endpoint instead

package/builtins/en/workflows/audit-architecture-backend.yaml

@@ -5,16 +5,20 @@ initial_step: plan
 
 loop_monitors:
   - cycle: [supervise, review]
-    threshold: 4
+    threshold: 3
     judge:
       persona: supervisor
       instruction: |
         The supervise → review cycle for the backend architecture audit has repeated {cycle_count} times.
-        Judge the overall completeness and quality of the audit, and decide whether the current results are acceptable.
+        Compare the audit report against the plan report and judge:
+        - Whether the audit scope has expanded since the previous cycle (new modules audited)
+        - Whether remaining unaudited modules can be completed in a reasonable number of cycles
       rules:
-        - condition: Quality is sufficient
+        - condition: Audit quality and scope are sufficient
           next: COMPLETE
-        - condition: Quality is insufficient with no prospect of improvement
+        - condition: Scope is expanding and progress continues
+          next: review
+        - condition: Scope is stalled with no prospect of improvement
           next: ABORT
 
 steps:
@@ -78,6 +82,10 @@ steps:
       - architecture
     instruction: architecture-audit-review
     edit: false
+    output_contracts:
+      report:
+        - name: 02-architecture-audit.md
+          format: architecture-audit
     rules:
       - condition: Re-audit complete
         next: supervise

package/builtins/en/workflows/audit-architecture-dual.yaml

@@ -5,16 +5,20 @@ initial_step: plan
 
 loop_monitors:
   - cycle: [supervise, review]
-    threshold: 4
+    threshold: 3
     judge:
       persona: supervisor
       instruction: |
         The supervise → review cycle for the dual architecture audit has repeated {cycle_count} times.
-        Judge the overall completeness and quality of the audit, and decide whether the current results are acceptable.
+        Compare the audit report against the plan report and judge:
+        - Whether the audit scope has expanded since the previous cycle (new modules audited)
+        - Whether remaining unaudited modules can be completed in a reasonable number of cycles
       rules:
-        - condition: Quality is sufficient
+        - condition: Audit quality and scope are sufficient
           next: COMPLETE
-        - condition: Quality is insufficient with no prospect of improvement
+        - condition: Scope is expanding and progress continues
+          next: review
+        - condition: Scope is stalled with no prospect of improvement
           next: ABORT
 
 steps:
@@ -82,6 +86,10 @@ steps:
       - architecture
     instruction: architecture-audit-review
     edit: false
+    output_contracts:
+      report:
+        - name: 02-architecture-audit.md
+          format: architecture-audit
     rules:
       - condition: Re-audit complete
         next: supervise

package/builtins/en/workflows/audit-architecture-frontend.yaml

@@ -5,16 +5,20 @@ initial_step: plan
 
 loop_monitors:
   - cycle: [supervise, review]
-    threshold: 4
+    threshold: 3
     judge:
       persona: supervisor
       instruction: |
         The supervise → review cycle for the frontend architecture audit has repeated {cycle_count} times.
-        Judge the overall completeness and quality of the audit, and decide whether the current results are acceptable.
+        Compare the audit report against the plan report and judge:
+        - Whether the audit scope has expanded since the previous cycle (new modules audited)
+        - Whether remaining unaudited modules can be completed in a reasonable number of cycles
       rules:
-        - condition: Quality is sufficient
+        - condition: Audit quality and scope are sufficient
           next: COMPLETE
-        - condition: Quality is insufficient with no prospect of improvement
+        - condition: Scope is expanding and progress continues
+          next: review
+        - condition: Scope is stalled with no prospect of improvement
           next: ABORT
 
 steps:
@@ -82,6 +86,10 @@ steps:
       - architecture
     instruction: architecture-audit-review
     edit: false
+    output_contracts:
+      report:
+        - name: 02-architecture-audit.md
+          format: architecture-audit
     rules:
       - condition: Re-audit complete
         next: supervise

package/builtins/en/workflows/audit-architecture.yaml

@@ -5,16 +5,20 @@ initial_step: plan
 
 loop_monitors:
   - cycle: [supervise, review]
-    threshold: 4
+    threshold: 3
     judge:
       persona: supervisor
       instruction: |
         The supervise → review cycle for the architecture audit has repeated {cycle_count} times.
-        Judge the overall completeness and quality of the audit, and decide whether the current results are acceptable.
+        Compare the audit report against the plan report and judge:
+        - Whether the audit scope has expanded since the previous cycle (new modules audited)
+        - Whether remaining unaudited modules can be completed in a reasonable number of cycles
       rules:
-        - condition: Quality is sufficient
+        - condition: Audit quality and scope are sufficient
           next: COMPLETE
-        - condition: Quality is insufficient with no prospect of improvement
+        - condition: Scope is expanding and progress continues
+          next: review
+        - condition: Scope is stalled with no prospect of improvement
           next: ABORT
 
 steps:
@@ -70,6 +74,10 @@ steps:
     knowledge: architecture
     instruction: architecture-audit-review
     edit: false
+    output_contracts:
+      report:
+        - name: 02-architecture-audit.md
+          format: architecture-audit
     rules:
       - condition: Re-audit complete
         next: supervise

package/builtins/en/workflows/audit-e2e.yaml

@@ -11,16 +11,20 @@ initial_step: plan
 
 loop_monitors:
   - cycle: [supervise, review]
-    threshold: 4
+    threshold: 3
     judge:
       persona: supervisor
       instruction: |
         The supervise → review cycle for the E2E audit has repeated {cycle_count} times.
-        Judge the overall completeness and quality of the audit, and decide whether the current results are acceptable.
+        Compare the audit report against the plan report and judge:
+        - Whether the audit scope has expanded since the previous cycle (new flows audited)
+        - Whether remaining unaudited flows can be completed in a reasonable number of cycles
       rules:
-        - condition: Quality is sufficient
+        - condition: Audit quality and scope are sufficient
           next: COMPLETE
-        - condition: Quality is insufficient with no prospect of improvement
+        - condition: Scope is expanding and progress continues
+          next: review
+        - condition: Scope is stalled with no prospect of improvement
           next: ABORT
 
 steps:
@@ -87,6 +91,10 @@ steps:
     knowledge:
       - e2e-testing
     instruction: e2e-audit-review
+    output_contracts:
+      report:
+        - name: 02-e2e-audit.md
+          format: e2e-audit
     rules:
       - condition: Re-audit complete
         next: supervise

package/builtins/en/workflows/audit-security.yaml

@@ -5,16 +5,20 @@ initial_step: plan
 
 loop_monitors:
   - cycle: [supervise, review]
-    threshold: 5
+    threshold: 3
     judge:
       persona: supervisor
       instruction: |
         The supervise → review cycle for the security audit has repeated {cycle_count} times.
-        Judge the overall quality and completeness of the audit, and decide whether to accept the current results.
+        Review the audit report and judge:
+        - Whether the audit scope has expanded since the previous cycle (new files audited)
+        - Whether remaining unaudited files can be completed in a reasonable number of cycles
       rules:
-        - condition: Quality is sufficient
+        - condition: Audit quality and scope are sufficient
           next: COMPLETE
-        - condition: Quality is insufficient with no prospect of improvement
+        - condition: Scope is expanding and progress continues
+          next: review
+        - condition: Scope is stalled with no prospect of improvement
           next: ABORT
 
 steps:
@@ -63,6 +67,10 @@ steps:
     knowledge: security
     instruction: audit-security-review
     edit: false
+    output_contracts:
+      report:
+        - name: 02-audit-security.md
+          format: audit-security
     rules:
       - condition: Re-audit complete
         next: supervise

package/builtins/en/workflows/audit-unit.yaml

@@ -11,16 +11,20 @@ initial_step: plan
 
 loop_monitors:
   - cycle: [supervise, review]
-    threshold: 4
+    threshold: 3
     judge:
       persona: supervisor
       instruction: |
         The supervise → review cycle for the unit audit has repeated {cycle_count} times.
-        Judge the overall completeness and quality of the audit, and decide whether the current results are acceptable.
+        Compare the audit report against the plan report and judge:
+        - Whether the audit scope has expanded since the previous cycle (new files or behaviors audited)
+        - Whether remaining unaudited items can be completed in a reasonable number of cycles
       rules:
-        - condition: Quality is sufficient
+        - condition: Audit quality and scope are sufficient
           next: COMPLETE
-        - condition: Quality is insufficient with no prospect of improvement
+        - condition: Scope is expanding and progress continues
+          next: review
+        - condition: Scope is stalled with no prospect of improvement
           next: ABORT
 
 steps:
@@ -89,6 +93,10 @@ steps:
     knowledge:
       - unit-testing
     instruction: unit-audit-review
+    output_contracts:
+      report:
+        - name: 02-unit-audit.md
+          format: unit-audit
     rules:
       - condition: Re-audit complete
         next: supervise

package/builtins/en/workflows/dual-cqrs-mini.yaml

@@ -61,6 +61,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     knowledge:
       - frontend
       - backend
@@ -229,6 +230,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     knowledge:
       - frontend
       - backend
@@ -263,6 +265,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     knowledge:
       - frontend
       - backend

package/builtins/en/workflows/dual-cqrs.yaml

@@ -70,6 +70,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     session: refresh
     knowledge:
       - frontend
@@ -137,6 +138,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     session: refresh
     knowledge:
       - frontend
@@ -283,6 +285,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     knowledge:
       - frontend
       - backend
@@ -341,6 +344,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     knowledge:
       - frontend
       - backend

package/builtins/en/workflows/dual-mini.yaml

@@ -60,6 +60,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     knowledge:
       - frontend
       - backend
@@ -224,6 +225,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     knowledge:
       - frontend
       - backend
@@ -257,6 +259,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     knowledge:
       - frontend
       - backend

package/builtins/en/workflows/dual.yaml

@@ -115,6 +115,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     session: refresh
     knowledge:
       - frontend
@@ -201,6 +202,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     session: refresh
     knowledge:
       - frontend
@@ -409,6 +411,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     knowledge:
       - frontend
       - react