git:20260831.6a178d4 to git:20260907.912dc76

---

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

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.