feat(agents): add Architectural Responsibility Mapping to phase-researcher pipeline (#1988)
Before framework-specific research, phase-researcher now maps each capability to its architectural tier owner (browser, frontend server, API, database, CDN). The planner sanity-checks task assignments against this map, and plan-checker enforces tier compliance as Dimension 7c. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -276,6 +276,12 @@ Priority: Context7 > Exa (verified) > Firecrawl (official docs) > Official GitHu
|
||||
|
||||
**Primary recommendation:** [one-liner actionable guidance]
|
||||
|
||||
## Architectural Responsibility Map
|
||||
|
||||
| Capability | Primary Tier | Secondary Tier | Rationale |
|
||||
|------------|-------------|----------------|-----------|
|
||||
| [capability] | [tier] | [tier or —] | [why this tier owns it] |
|
||||
|
||||
## Standard Stack
|
||||
|
||||
### Core
|
||||
@@ -520,6 +526,33 @@ cat "$phase_dir"/*-CONTEXT.md 2>/dev/null
|
||||
- User decided "simple UI, no animations" → don't research animation libraries
|
||||
- Marked as Claude's discretion → research options and recommend
|
||||
|
||||
## Step 1.5: Architectural Responsibility Mapping
|
||||
|
||||
Before diving into framework-specific research, map each capability in this phase to its standard architectural tier owner. This is a pure reasoning step — no tool calls needed.
|
||||
|
||||
**For each capability in the phase description:**
|
||||
|
||||
1. Identify what the capability does (e.g., "user authentication", "data visualization", "file upload")
|
||||
2. Determine which architectural tier owns the primary responsibility:
|
||||
|
||||
| Tier | Examples |
|
||||
|------|----------|
|
||||
| **Browser / Client** | DOM manipulation, client-side routing, local storage, service workers |
|
||||
| **Frontend Server (SSR)** | Server-side rendering, hydration, middleware, auth cookies |
|
||||
| **API / Backend** | REST/GraphQL endpoints, business logic, auth, data validation |
|
||||
| **CDN / Static** | Static assets, edge caching, image optimization |
|
||||
| **Database / Storage** | Persistence, queries, migrations, caching layers |
|
||||
|
||||
3. Record the mapping in a table:
|
||||
|
||||
| Capability | Primary Tier | Secondary Tier | Rationale |
|
||||
|------------|-------------|----------------|-----------|
|
||||
| [capability] | [tier] | [tier or —] | [why this tier owns it] |
|
||||
|
||||
**Output:** Include an `## Architectural Responsibility Map` section in RESEARCH.md immediately after the Summary section. This map is consumed by the planner for sanity-checking task assignments and by the plan-checker for verifying tier correctness.
|
||||
|
||||
**Why this matters:** Multi-tier applications frequently have capabilities misassigned during planning — e.g., putting auth logic in the browser tier when it belongs in the API tier, or putting data fetching in the frontend server when the API already provides it. Mapping tier ownership before research prevents these misassignments from propagating into plans.
|
||||
|
||||
## Step 2: Identify Research Domains
|
||||
|
||||
Based on phase description, identify what needs investigating:
|
||||
|
||||
@@ -369,6 +369,54 @@ Plans reduce {N} user decisions. Options:
|
||||
2. Split phase: [suggested grouping of D-XX into sub-phases]
|
||||
```
|
||||
|
||||
## Dimension 7c: Architectural Tier Compliance
|
||||
|
||||
**Question:** Do plan tasks assign capabilities to the correct architectural tier as defined in the Architectural Responsibility Map?
|
||||
|
||||
**Skip if:** No RESEARCH.md exists for this phase, or RESEARCH.md has no `## Architectural Responsibility Map` section. Output: "Dimension 7c: SKIPPED (no responsibility map found)"
|
||||
|
||||
**Process:**
|
||||
1. Read the phase's RESEARCH.md and extract the `## Architectural Responsibility Map` table
|
||||
2. For each plan task, identify which capability it implements and which tier it targets (inferred from file paths, action description, and artifacts)
|
||||
3. Cross-reference against the responsibility map — does the task place work in the tier that owns the capability?
|
||||
4. Flag any tier mismatch where a task assigns logic to a tier that doesn't own the capability
|
||||
|
||||
**Red flags:**
|
||||
- Auth validation logic placed in browser/client tier when responsibility map assigns it to API tier
|
||||
- Data persistence logic in frontend server when it belongs in database tier
|
||||
- Business rule enforcement in CDN/static tier when it belongs in API tier
|
||||
- Server-side rendering logic assigned to API tier when frontend server owns it
|
||||
|
||||
**Severity:** WARNING for potential tier mismatches. BLOCKER if a security-sensitive capability (auth, access control, input validation) is assigned to a less-trusted tier than the responsibility map specifies.
|
||||
|
||||
**Example — tier mismatch:**
|
||||
```yaml
|
||||
issue:
|
||||
dimension: architectural_tier_compliance
|
||||
severity: blocker
|
||||
description: "Task places auth token validation in browser tier, but Architectural Responsibility Map assigns auth to API tier"
|
||||
plan: "01"
|
||||
task: 2
|
||||
capability: "Authentication token validation"
|
||||
expected_tier: "API / Backend"
|
||||
actual_tier: "Browser / Client"
|
||||
fix_hint: "Move token validation to API route handler per Architectural Responsibility Map"
|
||||
```
|
||||
|
||||
**Example — non-security mismatch (warning):**
|
||||
```yaml
|
||||
issue:
|
||||
dimension: architectural_tier_compliance
|
||||
severity: warning
|
||||
description: "Task places data formatting in API tier, but Architectural Responsibility Map assigns it to Frontend Server"
|
||||
plan: "02"
|
||||
task: 1
|
||||
capability: "Date/currency formatting for display"
|
||||
expected_tier: "Frontend Server (SSR)"
|
||||
actual_tier: "API / Backend"
|
||||
fix_hint: "Consider moving display formatting to frontend server per Architectural Responsibility Map"
|
||||
```
|
||||
|
||||
## Dimension 8: Nyquist Compliance
|
||||
|
||||
Skip if: `workflow.nyquist_validation` is explicitly set to `false` in config.json (absent key = enabled), phase has no RESEARCH.md, or RESEARCH.md has no "Validation Architecture" section. Output: "Dimension 8: SKIPPED (nyquist_validation disabled or not applicable)"
|
||||
@@ -859,6 +907,7 @@ Plan verification complete when:
|
||||
- [ ] No tasks contradict locked decisions
|
||||
- [ ] Deferred ideas not included in plans
|
||||
- [ ] Overall status determined (passed | issues_found)
|
||||
- [ ] Architectural tier compliance checked (tasks match responsibility map tiers)
|
||||
- [ ] Cross-plan data contracts checked (no conflicting transforms on shared data)
|
||||
- [ ] CLAUDE.md compliance checked (plans respect project conventions)
|
||||
- [ ] Structured issues returned (if any found)
|
||||
|
||||
@@ -1026,6 +1026,8 @@ cat "$phase_dir"/*-DISCOVERY.md 2>/dev/null # From mandatory discovery
|
||||
**If CONTEXT.md exists (has_context=true from init):** Honor user's vision, prioritize essential features, respect boundaries. Locked decisions — do not revisit.
|
||||
|
||||
**If RESEARCH.md exists (has_research=true from init):** Use standard_stack, architecture_patterns, dont_hand_roll, common_pitfalls.
|
||||
|
||||
**Architectural Responsibility Map sanity check:** If RESEARCH.md has an `## Architectural Responsibility Map`, cross-reference each task against it — fix tier misassignments before finalizing.
|
||||
</step>
|
||||
|
||||
<step name="break_into_tasks">
|
||||
|
||||
Reference in New Issue
Block a user