How engineers consume contributions from architect, QA, DevSecOps, and UX — treating colleague inputs as requirements, not suggestions.
You don't work alone. Before you write a single line of code, other agents have provided structured inputs that shape your implementation. These are NOT suggestions. They are REQUIREMENTS.
The synergy matrix (config/synergy-matrix.yaml) defines what you receive:
| From | Type | Priority | What It Contains |
|---|---|---|---|
| Architect | design_input | REQUIRED (stories/epics) | Patterns, target files, approach, constraints, rationale |
| QA | qa_test_definition | REQUIRED (stories/epics) | TC-XXX criteria: what to test, how, expected results |
| DevSecOps | security_requirement | CONDITIONAL | Specific controls: auth method, input validation, secrets handling |
| UX | ux_spec | CONDITIONAL |
| States, interactions, accessibility, component patterns |
Before ANY work, call your role-specific group call:
eng_contribution_check() # or eng_contribution_check(task_id="...")
This reads your task's comments for typed contributions, checks the synergy matrix for what's required, and tells you:
fleet_request_input commands)If contributions are missing and your task is a story or epic, DO NOT START WORK. Call fleet_request_input to request the missing inputs.
Contributions appear as typed comments on your task:
**Contribution (design_input)** from architect:
Use adapter pattern for external API calls. Target files:
fleet/infra/api_client.py (new), fleet/core/models.py (extend).
Rationale: isolates external dependency, allows mocking in tests.
This is NOT optional advice. The architect has designed the approach. You implement it. If you disagree, raise it via fleet_chat(mention="architect") — do not silently deviate.
QA's test definition provides specific criteria:
TC-001: API client returns parsed response for valid input | unit | required
TC-002: API client raises specific exception for 4xx errors | unit | required
TC-003: Adapter handles timeout gracefully (3s default) | integration | required
Each TC-XXX becomes a checkpoint in your implementation:
Do NOT add criteria beyond what QA defined. If you discover additional test scenarios during implementation, call fleet_task_create(agent_name="qa-engineer") to let QA define them properly.
DevSecOps provides specific, actionable controls:
**Contribution (security_requirement)** from devsecops-expert:
- Use JWT with RS256 (not HS256) for token verification
- Pin all GitHub Actions to SHA (not @latest)
- Input validation: reject requests > 1MB, validate content-type
- No credentials in environment variables — use secrets manager
These are non-negotiable. If a security requirement conflicts with the design input, escalate to both architect and devsecops via fleet_escalate.
UX spec covers more than UI:
**Contribution (ux_spec)** from ux-designer:
CLI output: structured with clear sections, no raw JSON
Error messages: include what went wrong, what to do, error code
Config: validate on load, report all errors (not just first)
fleet_task_complete fires → creates approval for fleet-opsops_real_review → checks contributions were consumedThe contribution system is not bureaucracy. It's how 10 agents coordinate without meetings.
Some task types skip contributions entirely (subtask, blocker, concern, spike). For these, eng_contribution_check will show all_received: true immediately.
For tasks and simple stories where no contributions arrived but the task is in work stage, the PM has already determined this task doesn't need them. Proceed with work.