strategic-architecture-advisor git:20260830.d9f7ee5A

Immutable. This exact content is served forever at /api/v1/blob/99ed341ee968e9d6.

---
name: strategic-architecture-advisor
description: Acts as a strategic architect-advisor for EITR's own product direction (not a generated project's) - reviews current architecture against fresh industry research, hunts for non-obvious synergies between backlog ideas, designs the SDET onboarding flow across greenfield/brownfield x docs/no-docs x tests/no-tests, and records business-language questions only the user can answer. Trigger on requests like "проведи архитектурный ресёрч", "как SDET-помощник посмотри на архитектуру", "стратегическая сессия по архитектуре", "куда развивать EITR".
---

# Strategic Architecture Advisor

## Purpose

This is a periodic, deep-thinking session, not a code-review pass. The goal is to keep EITR's
product direction aligned with the [product vision](../../../docs/architecture/README.md#1-introduction--goals)
("one SDET + an AI-assistant subscription performs at the throughput of several, via agentic work
on a deterministic base") and with what the industry actually looks like _right now_, not at
training-cutoff. Load [`architecture-doc-writer`](../architecture-doc-writer/SKILL.md) alongside
this one if the session produces new ADRs or architecture-doc changes, which it usually should.

## Before anything else: load current state

1. Read `docs/architecture/README.md` and skim the topic files/`decisions/` for what's already
   decided - do not re-propose something already an ADR.
2. Read `TODO.md`'s "Стратегический бэклог" section (or equivalent) - the existing backlog is raw
   material for synergy-hunting, not a list to ignore in favor of inventing from scratch.

## Mandatory fresh web research

Never reason about "current industry best practice" from training data alone for this kind of
session - the AI-testing space moves fast enough that anything more than a few months stale is
liable to be wrong. At minimum, research:

- Agentic/autonomous QA platform architecture (how the market's actual leaders structure the
  orchestration layer, agent roles, human-in-the-loop gates).
- ISTQB's current syllabi relevant to _using_ AI for testing (CT-GenAI - not CT-AI, which is about
  testing AI-based systems as the product under test, a different and mostly irrelevant axis for
  EITR unless the user's target application is itself an AI feature).
- Context engineering / AI coding agent orchestration practice (this governs how EITR's own
  generated `CLAUDE.md`/`AGENTS.md`/skill files should be structured, and whether the
  `sdet-orchestrator` swarm-dispatch pattern matches current best practice or predates it).
- Brownfield/legacy test-suite adoption and migration strategy - this is the axis most likely to
  reveal a real gap, since EITR's flow is currently greenfield-shaped by default.
- The MCP ecosystem's current state (spec version, conformance-tooling norms) - EITR embeds an MCP
  server in every generated project, so protocol drift is a direct maintenance risk.

### Also mandatory: practitioner forums, not just vendor content

Vendor blogs and "N best practices for 2026" articles describe what's marketed - they rarely admit
what actually broke in production. Explicitly search practitioner-experience sources too: Reddit
(r/QA, r/softwaretesting, r/ExperiencedDevs and similar), Habr (strong Russian-language signal for
this specific domain - real teams publishing detailed build-logs of AI-agent QA harnesses, often
with concrete pitfalls named), DEV.to, Substack, and LinkedIn posts from practitioners (not
vendor/company pages). Search in both English and Russian - Habr in particular has repeatedly
surfaced directly-relevant, detailed war-stories this project benefits from that pure English-vendor
search does not. Weight a first-hand "here's what broke and how we fixed it" post above a
marketing-flavored listicle every time they conflict. Specifically look for: agents gaming their own
success criteria (fixing a test instead of the defect it found, mocking exactly what a test exists
to verify, taking a DOM/auth shortcut that skips the real user path), context-window/token-limit
failure modes at the scale this project's own agents will hit, and any independent team building
something structurally similar to a piece of EITR's own architecture - convergent validation (or
convergent disagreement) from an unrelated team is stronger signal than either result alone.

## The SDET day-1 flow matrix

Think through onboarding to a project as three largely-independent axes, not one linear path:

1. **Does a live application exist yet?** (nothing deployed vs. a real URL to point at)
2. **Does an existing automated test suite exist?** (blank slate vs. Selenium/Cypress/old
   Playwright/manual scripts already in place, possibly flaky or undocumented)
3. **Does usable documentation/requirements exist?** (nothing vs. a wiki/PRD vs. populated TMS
   tickets)

For each combination EITR is expected to actually encounter, walk through concretely what a human
SDET would do by hand, then ask: does EITR's current tooling make each step faster, or does the
human still have to do it manually because nothing covers that combination? A gap found this way is
worth far more than a feature invented in the abstract - it's the exact test this session exists to
run. Cross-reference the TODO backlog for cases that are already flagged versus a genuinely new gap.

## Hunt for non-obvious synergies, not just a longer list

The single highest-value output of this kind of session is usually not a new idea nobody thought of

- it's noticing that 3-4 items already in the backlog are actually **the same underlying mechanism
  viewed from different angles**, and building the shared mechanism once is cheaper and more coherent
  than building each separately. Concretely: before proposing a new feature, check whether it shares a
  data model, a trigger point, or a consumer with something else already proposed or already built.
  Say so explicitly when found - this is the "конфетка" moment the session is for, not a nice-to-have.

## Output

1. **A published Artifact** (load `artifact-design` first) with the findings: architecture
   critique + concrete fixes, the day-1 flow matrix with gaps called out, synergy findings, new idea
   proposals (each with a one-line "why now, grounded in what research"), practitioner-forum
   pitfalls worth guarding against explicitly (not just ideas to add - risks to design against, with
   which existing EITR mechanism already covers each one and which don't), and a short, explicitly
   prioritized next-batch shortlist - not an undifferentiated wall of ideas. Cite the actual research
   sources, including the practitioner-forum ones by name (a Habr/Reddit/DEV.to post is a legitimate
   citation here, not a lesser one).
2. **New ADRs** in `docs/architecture/decisions/` for anything this session actually resolves as a
   direction (not for open questions - those go in the strategic-questions file instead).
3. **Strategic questions for the user**, in a local, gitignored file (create
   `docs/architecture/STRATEGY-QUESTIONS.md` if it doesn't exist, and add it to `.gitignore` the
   first time) rather than blocking the session on them or losing them at session end. A strategic
   question is one only the user can answer as the business owner (target audience, monetization,
   compliance exposure, which of several valid directions to prioritize) - a technical question
   with a defensible right answer should just be resolved, not deferred here. Append with a date
   header per session so the file reads as a running log, and mark a question resolved (don't
   delete it) once the user has actually answered it in conversation.