strategic-architecture-advisor git:20260907.912dc76A

Immutable. This exact content is served forever at /api/v1/blob/9817efbeded607b5.

---
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) (Section 1)
("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 handling - EITR always builds a fresh, deterministic framework core
  regardless of what already exists on a project (never adopts or wraps an existing suite - see
  `decisions/0001-deterministic-core-only-scaffolder.md`); an existing suite, if any, is at most a
  _reference source_ to mine for signal (routes, locators, business-flow intent) feeding that same
  fresh generation. Research migration/adoption practice for what it reveals about extracting signal
  from legacy code, not to build an adoption path EITR deliberately doesn't want.
- 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.

### Also mandatory: per-provider changelogs/deprecations, and a careful OSS scan

Model/tool providers ship and deprecate capabilities fast enough that a session's own recommendation
can be built on a foundation that's already shifted. Check current changelogs and release notes for
at least: **Anthropic (mandatory - Claude models, Claude Code, the Agent SDK, MCP itself)**, then as
many of the following as time allows - OpenAI (Codex CLI, Agents SDK, API deprecations), xAI (Grok
models, Grok Build), Google (Gemini models, Antigravity CLI), and the tools this project's own
generated skills target or could target (Cursor, Devin Desktop, Copilot, Aider, and newer entrants
like Cline/Roo Code/Kilo Code/opencode/Grok Build that may not be in EITR's current 7-assistant
list; check `ai-agent-integration.md` against the current list before assuming it's complete). Also
check Playwright itself (not just MCP) - Microsoft's own guidance on agent-facing browser automation
has changed direction before (e.g. recommending a CLI over MCP for a large agent-token-cost
reduction) and a finding like that is exactly the kind of foundational shift this session exists to
catch.

Separately, scan public GitHub/GitLab repositories for patterns worth learning from - **ideas and
approaches only, never copied code**. Note the license of anything cited (prefer MIT/Apache/BSD
examples when citing a specific implementation approach) and never suggest vendoring or adapting
code from a repository without explicitly flagging its license and getting the user's confirmation
first - this session proposes patterns for EITR to build its own way, not a source of code to import.

### Also mandatory: everything EITR actually generates for, not just the AI layer

The provider/OSS scan above covers the AI-tooling ecosystem; separately and just as mandatory, check
official docs/changelogs/new-features/deprecations for the _target stack_ EITR generates
config/code for - i.e. everything the questionnaire (`packages/cli/src/questionnaire/schema.ts`)
actually offers, plus anything credibly on its near-term roadmap. Concretely, at minimum: Playwright
itself (not just MCP - new APIs, component-testing maturity, trace-viewer changes), Cypress (even
withheld from the CLI today per `decisions/`, its own roadmap still matters for if/when that
changes), each of the 5 target languages' own toolchains (TypeScript, JavaScript/Node, Python,
C#/.NET, Java), the 4 CI/CD targets (GitHub Actions, GitLab CI, Jenkins, TeamCity), Docker, and the
TMS integrations (Jira/Xray, Azure DevOps, TestRail, Zephyr). Include tools not yet integrated but
plausible near-term additions the user has flagged (e.g. Allure reporting) - research them now so a
future integration starts from current API shape, not stale assumptions. A breaking API change or a
new capability in any of these is exactly as load-bearing for EITR as an AI-provider change - the
generated output is only as current as this research is.

## 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.

### Also mandatory: the standing source list (check every session, regardless of what fresh search surfaces)

The sources below were found valuable enough in past sessions (2026-08-30) that they are now a
permanent, minimum check-list — re-visit each for anything new since the last session, on top of
whatever new sources that session's own open-ended search turns up. Never treat this list as a
substitute for fresh search; it's a floor, not a ceiling.

- **AI-provider changelogs:** `releasebot.io/updates/anthropic` (Anthropic — mandatory per the
  provider-changelog rule above), `developers.openai.com/api/docs/changelog` (OpenAI),
  `www.verdent.ai/guides/grok-for-coding-2026` (xAI Grok Build),
  `developers.googleblog.com` Gemini/Antigravity CLI posts (Google),
  `blog.modelcontextprotocol.io` (MCP spec itself).
- **Agentic QA / industry-architecture vendor content:**
  `testquality.com/agentic-qa-architecture-autonomous-testing-2026`,
  `katalon.com/resources-center/blog/what-is-agentic-qa-the-complete-guide-for-2026`.
- **ISTQB standards:** `istqb.org/istqb-releases-certified-tester-ai-testing-ct-ai-syllabus-version-2-0`
  and `istqb.org/certifications/gen-ai` (CT-GenAI syllabus updates specifically, not CT-AI).
- **Context engineering:** `sourcegraph.com/blog/context-engineering`,
  `www.reactify-solutions.com/articles/context-engineering-ai-agents-2026`.
- **MCP ecosystem overview:** `www.getknit.dev/blog/the-guide-to-the-mcp-ecosystem`.
- **Brownfield/migration practice:** `www.pcloudy.com/blogs/migrating-from-selenium-to-ai-agents`
  (read for legacy-signal-extraction technique, not as an adoption-path model EITR wants — see
  `decisions/0001`).
- **RTM/traceability automation:** `www.testmax.ai/blog/requirements-traceability-matrix-automation`.
- **Practitioner war-stories (Habr):** `habr.com/ru/articles/1074676` (agents fixing the test
  instead of the defect, over-mocking pitfalls, RED/GREEN tool gating) and
  `habr.com/ru/articles/1019656` (11-agent QA exoskeleton — JSON-scenario source of truth,
  ISTQB-technique scenario generation, context-decomposition). Re-check the authors'
  Habr profiles/blog indices for newer posts in the same vein, not just the two original URLs.
- **Playwright ecosystem specifically:** `qaskills.sh/blog/whats-new-playwright-2026`.
- **OSS agentic-browser pattern scan (ideas only, never code):**
  `github.com/browserbase/stagehand` (MIT), `github.com/Skyvern-AI/skyvern` (AGPL-3.0),
  `www.mindstudio.ai/blog/best-open-source-llms-agentic-coding-2026`.

## 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.