mirror of
https://github.com/azaion/annotations.git
synced 2026-06-21 08:41:06 +00:00
Oleksandr Bezdieniezhnykh
35 lines
2.9 KiB
Markdown
35 lines
2.9 KiB
Markdown
## Mode B: Solution Assessment
|
|
|
|
Triggered when `solution_draft*.md` files exist in OUTPUT_DIR.
|
|
|
|
**Role**: Professional software architect
|
|
|
|
Full 8-step research methodology applied to assessing and improving an existing solution draft.
|
|
|
|
**Input**: All files from INPUT_DIR + the latest (highest-numbered) `solution_draft##.md` from OUTPUT_DIR
|
|
|
|
**Task** (drives the 8-step engine):
|
|
1. Read the existing solution draft thoroughly
|
|
2. Derive or refresh the **Project Constraint Matrix** from all files in INPUT_DIR. Include required inputs/outputs, operating context, runtime envelope, data availability, lifecycle boundaries, non-functional targets, integration boundaries, security constraints, and explicit out-of-scope decisions.
|
|
3. Audit every component/decision in the existing draft against the Project Constraint Matrix before researching alternatives:
|
|
- If a component's documented implementation assumptions match the project constraints, keep it eligible and record evidence.
|
|
- If fit is unproven, mark it `Experimental only` until evidence is found.
|
|
- If constraints conflict, mark it `Rejected` and search for alternatives.
|
|
- If rejecting it changes product behavior or risk materially, escalate for user decision.
|
|
4. Research in internet extensively — for each component/decision in the draft, search for:
|
|
- Known problems and limitations of the chosen approach
|
|
- What practitioners say about using it in production
|
|
- Better alternatives that may have emerged recently
|
|
- Common failure modes and edge cases
|
|
- How competitors/similar projects solve the same problem differently
|
|
5. Search specifically for contrarian views: "why not [chosen approach]", "[chosen approach] criticism", "[chosen approach] failure"
|
|
6. Identify security weak points and vulnerabilities — search for CVEs, security advisories, and known attack vectors for each technology in the draft
|
|
7. Identify performance bottlenecks — search for benchmarks, load test results, and scalability reports
|
|
8. For each identified weak point, search for multiple solution approaches and compare them
|
|
9. For every revised candidate, prove exact fit against the Project Constraint Matrix. Do not select field-adjacent or "similar problem" options unless their intrinsic implementation constraints match the project.
|
|
10. Based on findings, form a new solution draft in the same format
|
|
|
|
**Save action**: Write `RESEARCH_DIR/06_component_fit_matrix.md` (or its split-folder equivalent under `RESEARCH_DIR/06_component_fit_matrix/`, per the splittable-artifacts convention in `00_project-integration.md`) before the final draft, then write `OUTPUT_DIR/solution_draft##.md` (incremented) using template: `templates/solution_draft_mode_b.md`
|
|
|
|
**Optional follow-up**: After Mode B completes, the user can request Phase 3 (Tech Stack Consolidation) or Phase 4 (Security Deep Dive) using the revised draft. These phases work identically to their Mode A descriptions in `steps/01_mode-a-initial-research.md`.
|