@fernado03/zoo-flow 0.10.0 → 0.11.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -85,12 +85,36 @@ npx @fernado03/zoo-flow@latest doctor
85
85
 
86
86
  ## Using Zoo Flow
87
87
 
88
- First run:
88
+ ### First run (both platforms)
89
89
 
90
90
  - Run `/scaffold-context` when the project needs local context docs.
91
91
  - Run `/setup-matt-pocock-skills` when tracker or triage config is needed.
92
92
 
93
- Daily use:
93
+ ### Claude Code
94
+
95
+ Claude Code reads `CLAUDE.md` automatically on startup. No mode switching needed.
96
+
97
+ **Daily use:**
98
+
99
+ - Open Claude Code in your project directory
100
+ - Describe tasks naturally: "Fix the login bug" → Claude proposes `/fix` workflow
101
+ - Or use slash commands directly: `/tweak`, `/fix`, `/feature`, `/review`, etc.
102
+ - Claude uses **behavioral profiles** (Architect/Implementer) defined in CLAUDE.md
103
+ - Multi-phase commands (like `/fix`, `/feature`) use the `Agent` tool to delegate between profiles
104
+
105
+ **Example:**
106
+ ```
107
+ You: "Fix the login bug"
108
+ Claude: "I'll use the /fix workflow. The architect will diagnose, then the implementer will fix it. Proceed?"
109
+ You: "Yes"
110
+ Claude: [Runs diagnostic, proposes fix, implements after approval]
111
+ ```
112
+
113
+ ### Zoo Code
114
+
115
+ Zoo Code uses three custom modes defined in `.roomodes`.
116
+
117
+ **Daily use:**
94
118
 
95
119
  - Start in `custom-orchestrator`, describe the task normally.
96
120
  - The orchestrator proposes a plain-language workflow; approve by number.
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "@fernado03/zoo-flow",
3
3
  "description": "Workflow control plane for Zoo Code.",
4
- "version": "0.10.0",
4
+ "version": "0.11.0",
5
5
  "type": "module",
6
6
  "bin": {
7
7
  "zoo-flow": "bin/zoo-flow.js"
@@ -3,6 +3,8 @@ name: diagnose
3
3
  description: Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test. Use when user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.
4
4
  ---
5
5
 
6
+ Uses scratch working memory for hypothesis tracking.
7
+
6
8
  # Diagnose
7
9
 
8
10
  RULE: glossary + ADRs. Skip phase only with explicit reason. DO NOT hypothesise before deterministic loop.
@@ -33,15 +35,26 @@ Rules:
33
35
  4. Capture exact error/output/timing.
34
36
  5. DO NOT continue until reproduced.
35
37
 
36
- ## 3. Hypotheses
38
+ ## 3. Hypotheses (with working memory)
39
+
40
+ Initialize session: `.scratch/diagnoses/<YYYY-MM-DD>/diagnose-<slug>/`
41
+
42
+ Write `<session-dir>/session.md` with symptom, repro steps, error signatures.
43
+
44
+ Generate 3–5 ranked falsifiable hypotheses. Write each to `<session-dir>/hypothesis-<N>.md`:
45
+
46
+ - **Statement**: `If {cause}, then {probe} will {result}`
47
+ - **Rank and confidence**
48
+ - **Rationale**
49
+ - **Instrumentation plan**: specific probe and expected outcome
50
+ - **Status**: pending / confirmed / rejected
51
+ - **Results**: (filled during phase 4)
37
52
 
38
- 1. Generate 3–5 ranked falsifiable hypotheses.
39
- 2. Format: `If {cause}, then {probe/change} will {observable result}`.
40
- 3. Drop vague hypotheses.
41
- 4. Show ranked list.
42
- 5. User AFK → proceed top hypothesis.
53
+ Drop vague hypotheses. Show ranked list. User AFK → proceed top hypothesis.
43
54
 
44
- ## 4. Instrument
55
+ ## 4. Instrument (with tracking)
56
+
57
+ Before each probe, read all `<session-dir>/hypothesis-*.md` files to maintain context.
45
58
 
46
59
  1. Map one probe to one hypothesis.
47
60
  2. Change one variable at a time.
@@ -51,6 +64,13 @@ Rules:
51
64
  6. DO NOT log everything.
52
65
  7. Perf: baseline/profiler/query plan before logs.
53
66
 
67
+ After each probe, update the corresponding hypothesis file with:
68
+ - Evidence observed
69
+ - Status update (confirmed / rejected)
70
+ - Next steps
71
+
72
+ Continue until root cause is confirmed or all hypotheses are rejected.
73
+
54
74
  ## 5. Fix + regression
55
75
 
56
76
  **OWNER: Implementer profile** (requires source-code edits)
@@ -93,10 +113,24 @@ Do not re-read unchanged files; use prior findings unless the file changed.
93
113
 
94
114
  For logs or large outputs, search for the failing marker/error first using `Grep`. Read only surrounding ranges needed to prove or disprove a hypothesis.
95
115
 
96
- ## 7. Save
116
+ ## 7. Save and synthesize
97
117
 
98
118
  **OWNER: Architect profile** (writes to `.scratch/`)
99
119
 
100
- Write the full diagnosis (hypotheses, instrumentation, root cause, fix) to `.scratch/diagnoses/<date>/diagnose-<slug>.md`.
120
+ Read all `<session-dir>/hypothesis-*.md` files.
121
+
122
+ Write `<session-dir>/root-cause.md`:
123
+ - Confirmed hypothesis with evidence trail
124
+ - Rejected hypotheses and why they failed
125
+ - Root cause explanation
126
+ - Fix applied (from phase 5-6)
127
+ - Preventive measures
128
+
129
+ Write `<session-dir>/diagnosis.md` with full log (hypotheses, instrumentation results, timeline).
101
130
 
102
- Return completion with: diagnosis file path, root cause summary, fix applied, status, and recommended next command (typically `/verify` then `/review` then `/commit-and-document`).
131
+ Return completion with:
132
+ - `<session-dir>/root-cause.md` path
133
+ - root cause summary
134
+ - fix applied
135
+ - status
136
+ - recommended next command (typically `/verify` then `/review` then `/commit-and-document`)
@@ -3,6 +3,8 @@ name: review
3
3
  description: Review a diff, branch, PR, or work-in-progress change against the requested spec, repo standards, architecture, and likely regressions. Use before committing non-trivial work.
4
4
  ---
5
5
 
6
+ Uses scratch working memory.
7
+
6
8
  # Review
7
9
 
8
10
  Purpose: answer whether the diff matches the spec, standards, architecture, and project intent.
@@ -37,9 +39,15 @@ Then read targeted diffs only:
37
39
 
38
40
  Read relevant specs, issues, PRDs, standards, docs, ADRs, security notes, or project conventions only when they affect the changed area or the user requested that axis.
39
41
 
40
- ## 3. Review axes
42
+ ## 3. Review axes (multi-pass with working memory)
43
+
44
+ Initialize session: `.scratch/reviews/<YYYY-MM-DD>/review-<slug>/`
45
+
46
+ Write `<session-dir>/session.md` with review target, base ref, scope.
41
47
 
42
- Standards axis:
48
+ ### Pass 1: Standards axis
49
+
50
+ Analyze and write `<session-dir>/standards.md`:
43
51
 
44
52
  - style
45
53
  - architecture
@@ -48,14 +56,24 @@ Standards axis:
48
56
  - security
49
57
  - project conventions
50
58
 
51
- Spec axis:
59
+ ### Pass 2: Spec axis
60
+
61
+ Read `<session-dir>/standards.md` for context.
62
+
63
+ Analyze and write `<session-dir>/spec.md`:
52
64
 
53
65
  - did it solve the requested problem?
54
66
  - did it change public behavior unexpectedly?
55
67
  - did it miss edge cases?
56
68
  - did it violate PRD, issue, or user intent?
57
69
 
58
- Security/Risk axis:
70
+ Cross-reference standards findings where relevant.
71
+
72
+ ### Pass 3: Security/Risk axis
73
+
74
+ Read `<session-dir>/standards.md` and `<session-dir>/spec.md`.
75
+
76
+ Analyze and write `<session-dir>/security.md`:
59
77
 
60
78
  - does the change touch auth, payments, PII, session data, or external API contracts?
61
79
  - does it introduce new dependencies or entitlements?
@@ -63,7 +81,9 @@ Security/Risk axis:
63
81
  - is there a regression path that would be hard to detect?
64
82
  - does the change affect audit logs or compliance obligations?
65
83
 
66
- For every Security/Risk finding, include the severity and a concrete mitigation suggestion. Omitting this axis is allowed when the change clearly cannot affect security (copy changes, comment fixes, test-only additions, docs-only updates).
84
+ For every Security/Risk finding, include severity and mitigation. Cross-reference previous passes.
85
+
86
+ Omit this axis when the change clearly cannot affect security (copy changes, comment fixes, test-only additions, docs-only updates).
67
87
 
68
88
  ## 4. Findings
69
89
 
@@ -94,12 +114,19 @@ End with exactly one result line:
94
114
  - `Review result: changes requested`
95
115
  - `Review result: blocked`
96
116
 
97
- ## 6. Save and complete
117
+ ## 6. Synthesize and complete
118
+
119
+ Read all angle files from `<session-dir>/` (standards.md, spec.md, security.md if present).
120
+
121
+ Write `<session-dir>/synthesis.md` with:
98
122
 
99
- Write the full review (findings, axes, result) to `.scratch/reviews/<date>/review-<slug>.md`.
123
+ - Summary of each axis
124
+ - Cross-cutting findings (issues spanning multiple axes)
125
+ - Prioritized findings by severity
126
+ - Result line: `approve` / `approve with nits` / `changes requested` / `blocked`
100
127
 
101
128
  Return completion with:
102
- - file path where review was saved
129
+ - `<session-dir>/synthesis.md` path
103
130
  - brief result line (approve / approve with nits / changes requested / blocked)
104
131
  - recommended next command
105
132
 
@@ -3,6 +3,8 @@ name: zoom-out
3
3
  description: Map the codebase at a high level to understand structure, modules, and relationships. Use when entering an unfamiliar codebase or planning large changes.
4
4
  ---
5
5
 
6
+ Uses scratch working memory for multi-dimension mapping.
7
+
6
8
  # Zoom Out
7
9
 
8
10
  RULE: Produce a high-level map, not detailed code analysis. Focus on structure and relationships.
@@ -12,9 +14,47 @@ RULE: Produce a high-level map, not detailed code analysis. Focus on structure a
12
14
  1. Use `Glob` to identify directory structure and file organization.
13
15
  2. Use `Grep` to find key patterns (entry points, exports, configurations).
14
16
  3. Use targeted `Read` on key files (README, package.json, main entry points).
15
- 4. Identify major modules, components, and their relationships.
16
- 5. Document map in `.scratch/zoom-out/<date>.md` using `Write`.
17
- 6. Include text-based diagrams showing structure and dependencies.
17
+
18
+ ## Multi-dimension mapping
19
+
20
+ Initialize session directory: `.scratch/zoom-out/<YYYY-MM-DD>-<slug>/`
21
+
22
+ Use `Write` to create `<session-dir>/session.md` with:
23
+ - Target area or scope
24
+ - Initial observations from step 3
25
+
26
+ ### Dimension 1: Architecture
27
+
28
+ Analyze and `Write` to `<session-dir>/architecture.md`:
29
+ - Module boundaries and responsibilities
30
+ - Key interfaces and abstractions
31
+ - Separation of concerns
32
+
33
+ ### Dimension 2: Data flow
34
+
35
+ Analyze and `Write` to `<session-dir>/data-flow.md`:
36
+ - Entry points (API endpoints, CLI commands, event handlers)
37
+ - Data transformations and processing steps
38
+ - State management and persistence
39
+ - External integrations
40
+
41
+ ### Dimension 3: Call graph
42
+
43
+ Analyze and `Write` to `<session-dir>/call-graph.md`:
44
+ - Key functions and their call chains
45
+ - Control flow patterns
46
+ - Dependencies between components
47
+ - Error propagation paths
48
+
49
+ ### Synthesis
50
+
51
+ `Read` all dimension files and synthesize insights.
52
+
53
+ `Write` to `<session-dir>/synthesis.md`:
54
+ - Cross-cutting architectural patterns
55
+ - Key dependencies and integration points
56
+ - Potential areas of concern or technical debt
57
+ - Recommended areas for deeper exploration
18
58
 
19
59
  ## Context economy
20
60
 
@@ -29,6 +69,6 @@ Do not re-read unchanged files; use prior findings unless the file changed.
29
69
  ## Complete
30
70
 
31
71
  Return completion with:
32
- - map document location
72
+ - `<session-dir>/synthesis.md` file path
33
73
  - high-level structure summary
34
74
  - recommended next command (typically `/explore` for deeper dive, or `/feature`/`/refactor` if changes needed)
@@ -0,0 +1,39 @@
1
+ # Scratch Working Memory
2
+
3
+ Use persistent multi-pass analysis for complex tasks. Skills opt in by declaring "Uses scratch working memory" after YAML frontmatter.
4
+
5
+ ## Protocol
6
+
7
+ ### 1. Initialize session
8
+ Create `.scratch/<category>/<YYYY-MM-DD>/<skill>-<slug>/` and write `session.md` with task summary and target.
9
+
10
+ ### 2. Write phase (per angle)
11
+ For each analysis angle:
12
+ - Perform analysis
13
+ - Write findings to `<session-dir>/<angle>.md` (e.g., `standards.md`, `spec.md`, `security.md`)
14
+ - Include: observations, issues (with severity), recommendations, cross-references to other angles
15
+
16
+ ### 3. Read phase (before next angle)
17
+ Before analyzing each new angle:
18
+ - Read all previous angle files from session directory
19
+ - Cross-reference findings
20
+ - Note reinforcements or contradictions
21
+
22
+ ### 4. Synthesize phase (final)
23
+ After all angles complete:
24
+ - Read all angle files
25
+ - Write `<session-dir>/synthesis.md`:
26
+ - Summary of each angle
27
+ - Cross-cutting concerns (issues spanning multiple angles)
28
+ - Prioritized recommendations (Blocker → High → Medium → Low → Nit)
29
+ - Confidence level per finding
30
+ - Write result summary
31
+ - Call `attempt_completion` with synthesis path and recommendations
32
+
33
+ ## Example
34
+ Review skill session: `.scratch/reviews/2026-01-15/review-auth-module/`
35
+ - `session.md` — task summary
36
+ - `standards.md` — style, architecture, test quality
37
+ - `spec.md` — problem solved? behavior changed? edge cases?
38
+ - `security.md` — auth, payments, PII, regressions
39
+ - `synthesis.md` — cross-cutting findings and prioritized recommendations
@@ -3,6 +3,8 @@ name: diagnose
3
3
  description: Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test. Use when user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.
4
4
  ---
5
5
 
6
+ Uses scratch working memory for hypothesis tracking.
7
+
6
8
  # Diagnose
7
9
 
8
10
  RULE: glossary + ADRs. Skip phase only with explicit reason. DO NOT hypothesise before deterministic loop.
@@ -33,15 +35,26 @@ Rules:
33
35
  4. Capture exact error/output/timing.
34
36
  5. DO NOT continue until reproduced.
35
37
 
36
- ## 3. Hypotheses
38
+ ## 3. Hypotheses (with working memory)
39
+
40
+ Initialize session: `.scratch/diagnoses/<YYYY-MM-DD>/diagnose-<slug>/`
41
+
42
+ Write `<session-dir>/session.md` with symptom, repro steps, error signatures.
43
+
44
+ Generate 3–5 ranked falsifiable hypotheses. Write each to `<session-dir>/hypothesis-<N>.md`:
45
+
46
+ - **Statement**: `If {cause}, then {probe} will {result}`
47
+ - **Rank and confidence**
48
+ - **Rationale**
49
+ - **Instrumentation plan**: specific probe and expected outcome
50
+ - **Status**: pending / confirmed / rejected
51
+ - **Results**: (filled during phase 4)
37
52
 
38
- 1. Generate 3–5 ranked falsifiable hypotheses.
39
- 2. Format: `If {cause}, then {probe/change} will {observable result}`.
40
- 3. Drop vague hypotheses.
41
- 4. Show ranked list.
42
- 5. User AFK → proceed top hypothesis.
53
+ Drop vague hypotheses. Show ranked list. User AFK → proceed top hypothesis.
43
54
 
44
- ## 4. Instrument
55
+ ## 4. Instrument (with tracking)
56
+
57
+ Before each probe, read all `<session-dir>/hypothesis-*.md` files to maintain context.
45
58
 
46
59
  1. Map one probe to one hypothesis.
47
60
  2. Change one variable at a time.
@@ -51,6 +64,13 @@ Rules:
51
64
  6. DO NOT log everything.
52
65
  7. Perf: baseline/profiler/query plan before logs.
53
66
 
67
+ After each probe, update the corresponding hypothesis file with:
68
+ - Evidence observed
69
+ - Status update (confirmed / rejected)
70
+ - Next steps
71
+
72
+ Continue until root cause is confirmed or all hypotheses are rejected.
73
+
54
74
  ## 5. Fix + regression
55
75
 
56
76
  **OWNER: code-tweaker** (requires source-code edits)
@@ -93,10 +113,24 @@ Do not re-read unchanged files; use prior findings unless the file changed.
93
113
 
94
114
  For logs or large outputs, search for the failing marker/error first. Read only surrounding ranges needed to prove or disprove a hypothesis.
95
115
 
96
- ## 7. Save
116
+ ## 7. Save and synthesize
97
117
 
98
118
  **OWNER: system-architect** (writes to `.scratch/`)
99
119
 
100
- Write the full diagnosis (hypotheses, instrumentation, root cause, fix) to `.scratch/diagnoses/<date>/diagnose-<slug>.md`.
120
+ Read all `<session-dir>/hypothesis-*.md` files.
121
+
122
+ Write `<session-dir>/root-cause.md`:
123
+ - Confirmed hypothesis with evidence trail
124
+ - Rejected hypotheses and why they failed
125
+ - Root cause explanation
126
+ - Fix applied (from phase 5-6)
127
+ - Preventive measures
128
+
129
+ Write `<session-dir>/diagnosis.md` with full log (hypotheses, instrumentation results, timeline).
101
130
 
102
- Call `attempt_completion` with: diagnosis file path, root cause summary, fix applied, status, and recommended next command (typically `/verify` then `/review` then `/commit-and-document`).
131
+ Call `attempt_completion` with:
132
+ - `<session-dir>/root-cause.md` path
133
+ - root cause summary
134
+ - fix applied
135
+ - status
136
+ - recommended next command (typically `/verify` then `/review` then `/commit-and-document`)
@@ -3,6 +3,8 @@ name: review
3
3
  description: Review a diff, branch, PR, or work-in-progress change against the requested spec, repo standards, architecture, and likely regressions. Use before committing non-trivial work.
4
4
  ---
5
5
 
6
+ Uses scratch working memory.
7
+
6
8
  # Review
7
9
 
8
10
  Purpose: answer whether the diff matches the spec, standards, architecture, and project intent.
@@ -37,9 +39,15 @@ Then read targeted diffs only:
37
39
 
38
40
  Read relevant specs, issues, PRDs, standards, docs, ADRs, security notes, or project conventions only when they affect the changed area or the user requested that axis.
39
41
 
40
- ## 3. Review axes
42
+ ## 3. Review axes (multi-pass with working memory)
43
+
44
+ Initialize session: `.scratch/reviews/<YYYY-MM-DD>/review-<slug>/`
45
+
46
+ Write `<session-dir>/session.md` with review target, base ref, scope.
41
47
 
42
- Standards axis:
48
+ ### Pass 1: Standards axis
49
+
50
+ Analyze and write `<session-dir>/standards.md`:
43
51
 
44
52
  - style
45
53
  - architecture
@@ -48,14 +56,24 @@ Standards axis:
48
56
  - security
49
57
  - project conventions
50
58
 
51
- Spec axis:
59
+ ### Pass 2: Spec axis
60
+
61
+ Read `<session-dir>/standards.md` for context.
62
+
63
+ Analyze and write `<session-dir>/spec.md`:
52
64
 
53
65
  - did it solve the requested problem?
54
66
  - did it change public behavior unexpectedly?
55
67
  - did it miss edge cases?
56
68
  - did it violate PRD, issue, or user intent?
57
69
 
58
- Security/Risk axis:
70
+ Cross-reference standards findings where relevant.
71
+
72
+ ### Pass 3: Security/Risk axis
73
+
74
+ Read `<session-dir>/standards.md` and `<session-dir>/spec.md`.
75
+
76
+ Analyze and write `<session-dir>/security.md`:
59
77
 
60
78
  - does the change touch auth, payments, PII, session data, or external API contracts?
61
79
  - does it introduce new dependencies or entitlements?
@@ -63,10 +81,9 @@ Security/Risk axis:
63
81
  - is there a regression path that would be hard to detect?
64
82
  - does the change affect audit logs or compliance obligations?
65
83
 
66
- For every Security/Risk finding, include the severity and a concrete
67
- mitigation suggestion. Omitting this axis is allowed when the change
68
- clearly cannot affect security (copy changes, comment fixes, test-only
69
- additions, docs-only updates).
84
+ For every Security/Risk finding, include severity and mitigation. Cross-reference previous passes.
85
+
86
+ Omit this axis when the change clearly cannot affect security (copy changes, comment fixes, test-only additions, docs-only updates).
70
87
 
71
88
  ## 4. Findings
72
89
 
@@ -97,12 +114,19 @@ End with exactly one result line:
97
114
  - `Review result: changes requested`
98
115
  - `Review result: blocked`
99
116
 
100
- ## 6. Save and complete
117
+ ## 6. Synthesize and complete
118
+
119
+ Read all angle files from `<session-dir>/` (standards.md, spec.md, security.md if present).
120
+
121
+ Write `<session-dir>/synthesis.md` with:
101
122
 
102
- Write the full review (findings, axes, result) to `.scratch/reviews/<date>/review-<slug>.md`.
123
+ - Summary of each axis
124
+ - Cross-cutting findings (issues spanning multiple axes)
125
+ - Prioritized findings by severity
126
+ - Result line: `approve` / `approve with nits` / `changes requested` / `blocked`
103
127
 
104
128
  Call `attempt_completion` with:
105
- - file path where review was saved
129
+ - `<session-dir>/synthesis.md` path
106
130
  - brief result line (approve / approve with nits / changes requested / blocked)
107
131
  - recommended next command
108
132
 
@@ -4,7 +4,9 @@ description: Tell the agent to zoom out and give broader context or a higher-lev
4
4
  disable-model-invocation: true
5
5
  ---
6
6
 
7
- Zoom out: map relevant modules + callers at higher abstraction. Use glossary vocabulary.
7
+ Uses scratch working memory for multi-dimension mapping.
8
+
9
+ Zoom out: map relevant modules + callers at higher abstraction using multi-dimension working memory. Use glossary vocabulary.
8
10
 
9
11
  ## Context economy
10
12
 
@@ -18,9 +20,61 @@ Do not re-read unchanged files; use prior findings unless the file changed.
18
20
 
19
21
  Start with `list_files` and `search_files`/`codebase_search`. Read representative files and key entrypoints, not every file in the area.
20
22
 
23
+ ## Multi-dimension mapping
24
+
25
+ Initialize session: `.scratch/explorations/<YYYY-MM-DD>/zoom-out-<slug>/`
26
+
27
+ Write `<session-dir>/session.md` with target area, scope, user request.
28
+
29
+ ### Dimension 1: Architecture
30
+
31
+ Map to `<session-dir>/architecture.md`:
32
+ - Module boundaries and responsibilities
33
+ - Dependency direction (who depends on whom)
34
+ - Seams (integration points, interfaces)
35
+ - Layers (presentation, business, data)
36
+
37
+ ### Dimension 2: Data flow
38
+
39
+ Read `<session-dir>/architecture.md` for context.
40
+
41
+ Map to `<session-dir>/data-flow.md`:
42
+ - Entry points (API, UI, CLI)
43
+ - Data transformations
44
+ - Persistence boundaries
45
+ - External integrations
46
+
47
+ Cross-reference architecture modules.
48
+
49
+ ### Dimension 3: Call graph
50
+
51
+ Read architecture and data-flow files.
52
+
53
+ Map to `<session-dir>/call-graph.md`:
54
+ - Key functions/methods
55
+ - Call chains (entry → core → exit)
56
+ - Async boundaries (events, queues, callbacks)
57
+ - Error propagation paths
58
+
59
+ Cross-reference previous dimensions.
60
+
61
+ ### Synthesis
62
+
63
+ Read all dimension files.
64
+
65
+ Write `<session-dir>/synthesis.md`:
66
+ - High-level structure (text diagram)
67
+ - Key patterns identified
68
+ - Coupling hotspots
69
+ - Open questions
70
+ - Recommended exploration paths
71
+
72
+ Write the exact file path to `.scratch/LAST-EXPLORATION.md` so next commands can find it.
73
+
21
74
  ## Complete
22
75
 
23
76
  Call `attempt_completion` with:
77
+ - `<session-dir>/synthesis.md` path
24
78
  - modules mapped (list)
25
79
  - key findings (summary)
26
80
  - status (complete / blocked with reason)