Refactor: consider splitting integration-manager responsibilities

[FL4TLiN3]

Description

The integration-manager expert has multiple responsibilities that may violate Best Practice #1 "Do One Thing Well".

Current State

integration-manager does:

1. Parallel orchestration - Runs functional-manager and usability-manager simultaneously
2. Results collection - Waits for and gathers reports from both managers
3. Trade-off analysis - Identifies conflicts between functional and usability requirements
4. Integration verification - Verifies ecosystem experts work together
5. Holistic assessment - Calculates combined quality scores

instruction = '''
## Workflow

### 1. Parallel Testing
Delegate to both managers simultaneously...

### 2. Collect Results
Wait for both managers...

### 3. Trade-off Analysis
Identify any conflicts...

### 4. Integration Verification
Verify ecosystem experts work together...

### 5. Holistic Assessment
Calculate overall quality score...
'''

Analysis

Per Best Practice #1:

Experts that do everything eventually break under their own weight.

Counter-argument from the code:

## Architecture Note
The 4-level delegation depth (create-expert → integration-manager → functional/usability-manager → expert-tester)
is intentional for separation of concerns

The 4-level depth is intentional, but the question is whether integration-manager itself is too broad.

Questions to Consider

1. Is the current design correct?

   • integration-manager as "integration" coordinator makes sense
   • Trade-off analysis is integration-specific
   • Maybe this is the right level of abstraction

2. Could responsibilities be split?

   • Separate quality-scorer for calculating scores
   • Separate trade-off-analyzer for conflict analysis
   • Keep integration-manager focused on orchestration only

3. What's the actual problem?

   • Is the instruction too long?
   • Is the expert unreliable in practice?
   • Or is this just theoretical concern?

Recommendation

This issue is for discussion. The current design may be acceptable if:

• integration-manager is still focused (all responsibilities relate to "integration")
• The expert performs reliably
• The instruction length is manageable

Mark as "needs triage" for team discussion.

Affected Areas

• apps/create-expert/src/lib/create-expert-toml.ts (INTEGRATION_MANAGER_INSTRUCTION)

Acceptance Criteria

• Team decision: keep current design or split
• If splitting: define new expert boundaries
• If keeping: document why this is appropriate exception to Principle Docs: Add related documentation links to runtime README #1

[github-actions]

🤖 Processing...

---