bmad-method-test-architecture-enterprise 2.0.2 → 2.0.3

package/cli/lib/evaluate/status.js

@@ -0,0 +1,184 @@
+/** Read-only progress view for a running or finished Evaluate invocation. */
+
+'use strict';
+
+const fs = require('node:fs');
+const path = require('node:path');
+
+const { readFolderFile } = require('./folder');
+
+const STALE_AFTER_MS = 90_000;
+const POLL_MS = 2000;
+const REPORT_EVERY_MS = 30_000;
+
+/** Only the runtime's flat invocation identifiers may name a run. */
+function validRunId(value) {
+  return typeof value === 'string' && /^[A-Za-z0-9_-]+$/.test(value) && value !== '.' && value !== '..';
+}
+
+function readRecord(folder, runId) {
+  const relative = `runs/${runId}/run.json`;
+  // An atomic progress replacement can land between the guarded path walk and
+  // open. Retry that one race, while retaining every link and file-type refusal.
+  let read;
+  for (let attempt = 0; attempt < 3; attempt += 1) {
+    read = readFolderFile(folder, relative);
+    if (read.ok || read.reason !== 'changed while it was read; run the command again') break;
+  }
+  if (!read.ok) return { error: `${relative} ${read.reason}` };
+  let record;
+  try {
+    record = JSON.parse(read.bytes.toString('utf8'));
+  } catch {
+    return { error: `${relative} is not valid JSON` };
+  }
+  if (record === null || typeof record !== 'object' || Array.isArray(record) || record.command !== 'run' || record.invocationId !== runId) {
+    return { error: `${relative} does not identify a tea-evaluate run` };
+  }
+  return { record };
+}
+
+/** Resolve the requested run, or the newest run whose guarded record identifies it. */
+function locateRun(folder, requested) {
+  if (requested !== undefined) {
+    if (!validRunId(requested)) return { error: `--run ${JSON.stringify(requested)} is not a run identifier` };
+    const read = readRecord(folder, requested);
+    return read.error === undefined ? { runId: requested, record: read.record } : read;
+  }
+  const runs = path.join(folder, 'runs');
+  let names;
+  try {
+    if (!fs.lstatSync(runs).isDirectory()) return { error: `${runs} is not a runs directory` };
+    names = fs.readdirSync(runs, { withFileTypes: true });
+  } catch (error) {
+    if (error.code === 'ENOENT') return { error: `${runs} holds no tea-evaluate run` };
+    return { error: `${runs} cannot be read (${error.code ?? error.message})` };
+  }
+  for (const entry of names
+    .map((item) => item.name)
+    .filter(validRunId)
+    .sort()
+    .toReversed()) {
+    const read = readRecord(folder, entry);
+    if (read.error === undefined) return { runId: entry, record: read.record };
+  }
+  return { error: `${runs} holds no tea-evaluate run` };
+}
+
+function elapsedText(ms) {
+  if (!Number.isFinite(ms) || ms < 0) return 'unknown';
+  const seconds = Math.floor(ms / 1000);
+  const hours = Math.floor(seconds / 3600);
+  const minutes = Math.floor((seconds % 3600) / 60);
+  return `${hours}h ${minutes}m ${seconds % 60}s`;
+}
+
+function shortDuration(ms) {
+  const seconds = Math.floor(ms / 1000);
+  if (seconds < 60) return `${seconds}s`;
+  if (seconds < 3600) return `${Math.floor(seconds / 60)}m ${seconds % 60}s`;
+  return elapsedText(ms);
+}
+
+function safeText(value) {
+  return typeof value === 'string' ? value.replaceAll(/[\r\n\t]+/g, ' ').trim() : '';
+}
+
+function costAmount(value) {
+  return typeof value === 'string' && /^(?:0|[1-9]\d*)(?:\.\d+)?$/.test(value) ? value : null;
+}
+
+function costText(usage) {
+  if (usage === null || typeof usage !== 'object' || usage.scope !== 'trials-only') return 'trial cost unknown (trials only)';
+  const missing = Number.isInteger(usage.missingReports) && usage.missingReports >= 0 ? usage.missingReports : null;
+  const reported = costAmount(usage.reportedTrialCostUsd);
+  const complete = costAmount(usage.trialCostUsd);
+  if (complete !== null && missing === 0) return `trial cost $${complete} (trials only)`;
+  const parts = ['trial cost unknown'];
+  if (reported !== null) parts.push(`reported $${reported}`);
+  if (missing !== null) parts.push(`${missing} missing report${missing === 1 ? '' : 's'}`);
+  return `${parts[0]} (${[...parts.slice(1), 'trials only'].join('; ')})`;
+}
+
+function statusOf(runId, record, now = Date.now()) {
+  const progress = record.progress && typeof record.progress === 'object' && !Array.isArray(record.progress) ? record.progress : {};
+  const outcome = record.outcome && typeof record.outcome === 'object' ? record.outcome : null;
+  const updatedAt = Date.parse(progress.updatedAt);
+  const startedAt = Date.parse(progress.startedAt ?? record.startedAt);
+  const terminal = record.completed === true || outcome !== null;
+  const stale = !terminal && (!Number.isFinite(updatedAt) || now - updatedAt >= STALE_AFTER_MS);
+  const state = terminal ? (record.completed === true ? 'complete' : 'stopped') : stale ? 'stale' : 'live';
+  const completedTrials = Number.isInteger(progress.completedTrials) && progress.completedTrials >= 0 ? progress.completedTrials : null;
+  const totalTrials = Number.isInteger(progress.totalTrials) && progress.totalTrials >= 0 ? progress.totalTrials : null;
+  const lastElapsed = Number.isFinite(progress.elapsedMs) && progress.elapsedMs >= 0 ? progress.elapsedMs : null;
+  const elapsed =
+    lastElapsed === null
+      ? terminal && Number.isFinite(record.durationMs)
+        ? record.durationMs
+        : stale
+          ? Number.NaN
+          : now - startedAt
+      : lastElapsed;
+  const parts = [`run ${runId}: ${state}`];
+  if (safeText(progress.phase)) parts.push(safeText(progress.phase));
+  if (safeText(progress.detail)) parts.push(safeText(progress.detail));
+  if (Number.isFinite(progress.phaseElapsedMs) && progress.phaseElapsedMs >= 0) {
+    parts.push(`phase elapsed ${elapsedText(progress.phaseElapsedMs)}`);
+  }
+  if (completedTrials !== null && totalTrials !== null) parts.push(`trials ${completedTrials}/${totalTrials}`);
+  parts.push(`elapsed ${elapsedText(elapsed)}`);
+  const phaseDurations = progress.phaseDurationsMs;
+  if (phaseDurations !== null && typeof phaseDurations === 'object' && !Array.isArray(phaseDurations)) {
+    const finishedPhases = Object.entries(phaseDurations)
+      .filter(([phase, ms]) => safeText(phase) !== '' && Number.isFinite(ms) && ms >= 0)
+      .map(([phase, ms]) => `${safeText(phase)} ${shortDuration(ms)}`);
+    if (finishedPhases.length > 0) parts.push(`phase times ${finishedPhases.join(', ')}`);
+  }
+  parts.push(
+    costText(progress.usage),
+    Number.isFinite(updatedAt)
+      ? `last update ${new Date(updatedAt).toISOString()} (${elapsedText(Math.max(0, now - updatedAt))} ago)`
+      : 'last update unknown',
+  );
+  if (outcome !== null) {
+    if (Number.isInteger(outcome.exitCode)) parts.push(`exit ${outcome.exitCode}`);
+    if (safeText(outcome.signal)) parts.push(`signal ${safeText(outcome.signal)}`);
+  }
+  return { runId, state, terminal, stale, line: parts.join(' | '), progress, outcome };
+}
+
+function sleep(ms) {
+  return new Promise((resolve) => setTimeout(resolve, ms));
+}
+
+/** Emit one snapshot, then material changes and periodic heartbeats until the run ends. */
+async function runStatusCommand(folder, { run, follow = false, emit, pollMs = POLL_MS, reportEveryMs = REPORT_EVERY_MS } = {}) {
+  const located = locateRun(folder, run);
+  if (located.error !== undefined) return { exitCode: 64, message: located.error };
+  const { runId } = located;
+  let lastIdentity = null;
+  let lastReportAt = 0;
+  for (;;) {
+    const read = readRecord(folder, runId);
+    if (read.error !== undefined) return { exitCode: 12, message: read.error };
+    const now = Date.now();
+    const status = statusOf(runId, read.record, now);
+    const identity = JSON.stringify({
+      state: status.state,
+      phase: status.progress.phase,
+      detail: status.progress.detail,
+      completedTrials: status.progress.completedTrials,
+      totalTrials: status.progress.totalTrials,
+      outcome: status.outcome,
+    });
+    if (lastIdentity !== identity || now - lastReportAt >= reportEveryMs) {
+      emit?.(status.line);
+      lastIdentity = identity;
+      lastReportAt = now;
+    }
+    if (!follow || status.terminal) return { exitCode: 0, message: status.line, status };
+    await sleep(pollMs);
+  }
+}
+
+module.exports = { STALE_AFTER_MS, locateRun, runStatusCommand, statusOf, validRunId };

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "bmad-method-test-architecture-enterprise",
-  "version": "2.0.2",
+  "version": "2.0.3",
   "description": "Master Test Architect for quality strategy, test automation, and release gates",
   "keywords": [
     "bmad",
@@ -89,7 +89,7 @@
     "release:minor": "gh workflow run publish.yaml -f channel=latest -f bump=minor",
     "release:next": "gh workflow run publish.yaml -f channel=next",
     "release:patch": "gh workflow run publish.yaml -f channel=latest -f bump=patch",
-    "test": "npm run test:conflict-markers && npm run test:schemas && npm run test:install && npm run test:evaluate-guidance && npm run test:evaluate-authoring && npm run test:evaluate-gap-loop && npm run test:evaluate-dogfood && npm run test:evaluate-check && npm run test:evaluate-compare && npm run test:evaluate-before-state && npm run test:evaluate-ci-gates && npm run test:evaluate-ci-tiers && npm run test:evaluate-ci-repositories:tagged-release-pr && npm run test:evaluate-ci-repositories:tagged-release-merge && npm run test:evaluate-ci-repositories:tagged-release-release && npm run test:evaluate-ci-repositories:nightly-deploy-pr && npm run test:evaluate-ci-repositories:nightly-deploy-merge && npm run test:evaluate-ci-repositories:nightly-deploy-scheduled && npm run test:evaluate-ci-repositories:nightly-deploy-release && npm run test:evaluate-ci-render && npm run test:evaluate-pr-mcp && npm run test:evaluate-pr-api && npm run test:evaluate-pr-suite && npm run test:evaluate-pr-workflow && npm run test:evaluate-pr-tool-use && npm run test:evaluate-pr-promptfoo && npm run test:evaluate-pr-ai-feature && npm run test:evaluate-pr-test-review && npm run test:evaluate-pr-gap-loop && npm run test:evaluate-pr-learn && npm run test:evaluate-pr-tutorial && npm run test:evaluate-partitions && npm run test:evaluate-partition-plans-views-and-check && npm run test:evaluate-partition-plans-preflight-and-run && npm run test:evaluate-partition-plans-score && npm run test:evaluate-partition-plans-attempts-seal-and-mappings && npm run test:evaluate-partition-plans-attempts-records && npm run test:evaluate-partition-plans-attempts-gameability && npm run test:evaluate-interpret && npm run test:evaluate-calibration && npm run test:evaluate-boundaries && npm run test:evaluate-preflight && npm run test:evaluate-isolation-conformance && npm run test:evaluate-mutation:qualification-basics && npm run test:evaluate-mutation:qualification-guards && npm run test:evaluate-mutation:recovery && npm run test:evaluate-mutation:journals && npm run test:evaluate-run && npm run test:evaluate-aggregate && npm run test:evaluate-confinement && npm run test:evaluate-confinement-audit && npm run test:evaluate-confinement-history && npm run test:evaluate-confinement-git-state && npm run test:evaluate-confinement-network && npm run test:evaluate-held-inputs && npm run test:evaluate-arms-historical && npm run test:evaluate-arms-deployments && npm run test:evaluate-evaluators && npm run test:evaluate-evaluators-agent-version && npm run test:evaluate-agents && npm run test:evaluate-agents-importers && npm run test:evaluate-agents-sealed-brief && npm run test:evaluate-held-attempts && npm run test:evaluate-private && npm run test:evaluate-records && npm run test:evaluate-mcp && npm run test:evaluate-api && npm run test:evaluate-workflow && npm run test:evaluate-tool-use && npm run test:evaluate-promptfoo && npm run test:evaluate-learned-framework && npm run test:docs-tutorial && npm run test:knowledge && npm run test:criteria-fragments && npm run test:doc-count-sources && npm run test:planning-doc-sources && npm run test:doc-counts && npm run test:doc-claim-sources && npm run test:doc-claims && npm run test:doc-invocation-entry && npm run test:doc-invocations && npm run test:doc-link-anchors && npm run test:docs-build-names && npm run test:docs-evaluate-sidebar && npm run test:docs-gap-reader && npm run test:enforce-hook && npm run test:framework-scaffold && npm run test:isolation-primitives && npm run test:atdd-isolation && npm run test:atdd-net-guard && npm run test:atdd-scoring && npm run test:atdd-workflow-guidance && npm run test:generation-healing && npm run test:framework-scaffold-install-isolation && npm run test:transcript-harness && npm run test:suite-manifest && npm run test:teach-me-testing-scoring && npm run test:eval-data && npm run test:eval-atdd-data && npm run test:eval-ci-data && npm run test:eval-framework-scaffold-data && npm run test:eval-nfr-data && npm run test:nfr-validate-corpus && npm run test:nfr-evidence-guidance && npm run test:eval-test-design-data && npm run test:eval-trace-data && npm run test:eval-routing-data && npm run test:eval-routing-boundaries && npm run test:eval-routing-evidence && npm run test:eval-transcript-data && npm run test:eval-teach-me-testing-data && npm run test:eval-schemas && npm run test:eval-diagnostics && npm run test:eval-replay && npm run test:eval-quality-corpus && npm run test:schema-versions && npm run test:contract-sources && npm run test:contracts && npm run test:contract-oracles && npm run test:probe-sources && npm run test:test-design-qualification && npm run test:test-review-qualification && npm run test:trace-qualification && npm run test:nfr-qualification && npm run test:ci-qualification && npm run test:probe-corpus && npm run test:compare-dominance && npm run test:compare-eval-runs && npm run test:trial-set-scoring && npm run test:automate-eval-fixture && npm run test:eval-automate-data && npm run test:clock-port && npm run test:probe-conformance && npm run test:corpus-conformance && npm run test:file-system-conformance && npm run test:file-system-port && npm run test:probe-targets && npm run test:port-totality && npm run test:ci-coverage && npm run test:ci-coverage-filters && npm run test:install-actionlint && npm run test:workflows-lint && npm run test:install-linux-sandbox && npm run test:shards && npm run test:groups && npm run test:cli && npm run test:test-review-pr-scope && npm run test:test-review-report && npm run test:test-review-rubric && npm run test:bmad-output-gated && npm run test:release-metadata && npm run test:release-notes && npm run test:lockfile-age && npm run test:lockfile-age-cache && npm run test:licences && npm run test:supply-chain && npm run test:boundary && npm run test:direction && npm run test:lineage && npm run test:guard-publish && npm run test:layering-boundary-lineage && npm run test:changelog && npm run test:tea-workflow-descriptions && npm run test:docs-mermaid && npm run test:llms-headroom && npm run validate:schemas && npm run lint && npm run lint:md && npm run format:check",
+    "test": "npm run test:conflict-markers && npm run test:schemas && npm run test:install && npm run test:evaluate-guidance && npm run test:evaluate-authoring && npm run test:evaluate-gap-loop && npm run test:evaluate-dogfood && npm run test:evaluate-check && npm run test:evaluate-compare && npm run test:evaluate-before-state && npm run test:evaluate-ci-gates && npm run test:evaluate-ci-tiers && npm run test:evaluate-ci-repositories:tagged-release-pr && npm run test:evaluate-ci-repositories:tagged-release-merge && npm run test:evaluate-ci-repositories:tagged-release-release && npm run test:evaluate-ci-repositories:nightly-deploy-pr && npm run test:evaluate-ci-repositories:nightly-deploy-merge && npm run test:evaluate-ci-repositories:nightly-deploy-scheduled && npm run test:evaluate-ci-repositories:nightly-deploy-release && npm run test:evaluate-ci-render && npm run test:evaluate-pr-mcp && npm run test:evaluate-pr-api && npm run test:evaluate-pr-suite && npm run test:evaluate-pr-workflow && npm run test:evaluate-pr-tool-use && npm run test:evaluate-pr-promptfoo && npm run test:evaluate-pr-ai-feature && npm run test:evaluate-pr-test-review && npm run test:evaluate-pr-gap-loop && npm run test:evaluate-pr-learn && npm run test:evaluate-pr-tutorial && npm run test:evaluate-partitions && npm run test:evaluate-partition-plans-views-and-check && npm run test:evaluate-partition-plans-preflight-and-run && npm run test:evaluate-partition-plans-score && npm run test:evaluate-partition-plans-attempts-seal-and-mappings && npm run test:evaluate-partition-plans-attempts-records && npm run test:evaluate-partition-plans-attempts-gameability && npm run test:evaluate-interpret && npm run test:evaluate-calibration && npm run test:evaluate-boundaries && npm run test:evaluate-preflight && npm run test:evaluate-isolation-conformance && npm run test:evaluate-mutation:qualification-basics && npm run test:evaluate-mutation:qualification-guards && npm run test:evaluate-mutation:recovery && npm run test:evaluate-mutation:journals && npm run test:evaluate-run && npm run test:evaluate-progress && npm run test:evaluate-aggregate && npm run test:evaluate-confinement && npm run test:evaluate-confinement-audit && npm run test:evaluate-confinement-history && npm run test:evaluate-confinement-git-state && npm run test:evaluate-confinement-network && npm run test:evaluate-held-inputs && npm run test:evaluate-arms-historical && npm run test:evaluate-arms-deployments && npm run test:evaluate-evaluators && npm run test:evaluate-evaluators-agent-version && npm run test:evaluate-agents && npm run test:evaluate-agents-importers && npm run test:evaluate-agents-sealed-brief && npm run test:evaluate-held-attempts && npm run test:evaluate-private && npm run test:evaluate-records && npm run test:evaluate-mcp && npm run test:evaluate-api && npm run test:evaluate-workflow && npm run test:evaluate-tool-use && npm run test:evaluate-promptfoo && npm run test:evaluate-learned-framework && npm run test:docs-tutorial && npm run test:knowledge && npm run test:criteria-fragments && npm run test:doc-count-sources && npm run test:planning-doc-sources && npm run test:doc-counts && npm run test:doc-claim-sources && npm run test:doc-claims && npm run test:doc-invocation-entry && npm run test:doc-invocations && npm run test:doc-link-anchors && npm run test:docs-build-names && npm run test:docs-evaluate-sidebar && npm run test:docs-gap-reader && npm run test:enforce-hook && npm run test:framework-scaffold && npm run test:isolation-primitives && npm run test:atdd-isolation && npm run test:atdd-net-guard && npm run test:atdd-scoring && npm run test:atdd-workflow-guidance && npm run test:generation-healing && npm run test:framework-scaffold-install-isolation && npm run test:transcript-harness && npm run test:suite-manifest && npm run test:teach-me-testing-scoring && npm run test:eval-data && npm run test:eval-atdd-data && npm run test:eval-ci-data && npm run test:eval-framework-scaffold-data && npm run test:eval-nfr-data && npm run test:nfr-validate-corpus && npm run test:nfr-evidence-guidance && npm run test:eval-test-design-data && npm run test:eval-trace-data && npm run test:eval-routing-data && npm run test:eval-routing-boundaries && npm run test:eval-routing-evidence && npm run test:eval-transcript-data && npm run test:eval-teach-me-testing-data && npm run test:eval-schemas && npm run test:eval-diagnostics && npm run test:eval-replay && npm run test:eval-quality-corpus && npm run test:schema-versions && npm run test:contract-sources && npm run test:contracts && npm run test:contract-oracles && npm run test:probe-sources && npm run test:test-design-qualification && npm run test:test-review-qualification && npm run test:trace-qualification && npm run test:nfr-qualification && npm run test:ci-qualification && npm run test:probe-corpus && npm run test:compare-dominance && npm run test:compare-eval-runs && npm run test:trial-set-scoring && npm run test:automate-eval-fixture && npm run test:eval-automate-data && npm run test:clock-port && npm run test:probe-conformance && npm run test:corpus-conformance && npm run test:file-system-conformance && npm run test:file-system-port && npm run test:probe-targets && npm run test:port-totality && npm run test:ci-coverage && npm run test:ci-coverage-filters && npm run test:install-actionlint && npm run test:workflows-lint && npm run test:install-linux-sandbox && npm run test:shards && npm run test:groups && npm run test:cli && npm run test:test-review-pr-scope && npm run test:test-review-report && npm run test:test-review-rubric && npm run test:bmad-output-gated && npm run test:release-metadata && npm run test:release-notes && npm run test:lockfile-age && npm run test:lockfile-age-cache && npm run test:licences && npm run test:supply-chain && npm run test:boundary && npm run test:direction && npm run test:lineage && npm run test:guard-publish && npm run test:layering-boundary-lineage && npm run test:changelog && npm run test:tea-workflow-descriptions && npm run test:docs-mermaid && npm run test:llms-headroom && npm run validate:schemas && npm run lint && npm run lint:md && npm run format:check",
     "test:atdd-isolation": "node test/test-atdd-isolation.js",
     "test:atdd-net-guard": "node test/test-atdd-net-guard.js",
     "test:atdd-scoring": "node test/test-atdd-scoring.js",
@@ -209,6 +209,7 @@
     "test:evaluate-pr-workflow": "node test/test-evaluate-pr-tier.js workflow",
     "test:evaluate-preflight": "node test/test-evaluate-preflight.js",
     "test:evaluate-private": "node test/test-evaluate-evaluators.js --group=private",
+    "test:evaluate-progress": "node test/test-evaluate-progress.js",
     "test:evaluate-promptfoo": "node test/test-evaluate-promptfoo.js",
     "test:evaluate-records": "node test/test-evaluate-evaluators.js --group=records",
     "test:evaluate-run": "node test/test-evaluate-run.js --group=run",

package/skills/bmad-tea/SKILL.md

@@ -78,11 +78,11 @@ Dispatch on a clear match by invoking the item's `skill` or executing its `promp
 
 ### Framework and CI Setup Routing
 
-TF invokes `bmad-testarch-framework`, the canonical owner of framework and CI setup. CI invokes the installed `bmad-testarch-ci` compatibility entry with CI scope preset. Preserve both codes, names, custom menu overrides, requested scope and operation. A request for framework and pipeline setup routes directly to TF with `setup_scope = both`. The shared router asks “Do you want CI too?” once when setup leaves CI intent unclear.
+TF invokes `bmad-testarch-framework` for framework setup. CI invokes the same skill with `setup_scope = ci`. Preserve both codes, custom menu overrides, requested scope and operation. A request for framework and pipeline setup routes to TF with `setup_scope = both`. The shared router asks “Do you want CI too?” once when setup leaves CI intent unclear.
 
 ### Test Generation Routing
 
-AT invokes `bmad-testarch-atdd`, the red-mode entry of the canonical `bmad-testarch-automate` skill. TA invokes `bmad-testarch-automate` with expand as its default. Preserve both menu codes, both invocation names, custom menu overrides, the requested operation and any explicit red or expand intent. Red writes acceptance tests before implementation and checks the intended failure; expand adds passing coverage for implemented code. Create runs run-and-heal by default in both modes. Validate and Edit report their own checks without repair. A mixed implemented/unimplemented request still needs the deciding scope or sequence when the user has supplied neither.
+AT invokes `bmad-testarch-automate` with `test_mode = red`. TA invokes the same skill with expand as its default. Preserve both menu codes, custom menu overrides, the requested operation and any explicit red or expand intent. Red writes acceptance tests before implementation and checks the intended failure; expand adds passing coverage for implemented code. Create runs run-and-heal by default in both modes. Validate and Edit report their own checks without repair. A mixed implemented/unimplemented request still needs the deciding scope or sequence when the user has supplied neither.
 
 ### Routing Ambiguity Boundaries
 

package/skills/bmad-tea/customize.toml

@@ -74,13 +74,13 @@ skill = "bmad-testarch-framework"
 
 [[agent.menu]]
 code = "CI"
-description = "Continuous Integration: scaffold CI/CD quality pipeline through the combined framework skill"
-skill = "bmad-testarch-ci"
+description = "Continuous Integration: scaffold a CI/CD quality pipeline through Framework CI scope"
+skill = "bmad-testarch-framework"
 
 [[agent.menu]]
 code = "AT"
-description = "ATDD: generate and verify failing acceptance tests in red mode before development"
-skill = "bmad-testarch-atdd"
+description = "ATDD: generate and verify failing acceptance tests through Automate red mode"
+skill = "bmad-testarch-automate"
 
 [[agent.menu]]
 code = "TA"

package/skills/bmad-teach-me-testing/steps-c/step-04-session-01.md

@@ -93,8 +93,8 @@ Present this content (mostly autonomous, clear and educational):
 
 TEA is a comprehensive test architecture framework that provides:
 
-- **8 Workflows:** Teach Me Testing, Test Design, Framework and CI Setup, Automation (red and expand modes), Test Review, NFR Evidence Audit, Trace, Evaluate. The CI and ATDD commands and their menu codes remain available.
-- **Framework and CI setup:** One `bmad-testarch-framework` skill handles framework only, CI only, or both. The `bmad-testarch-ci` command and `CI` menu code start its CI setup. TEA infers the scope from your prompt and asks "Do you want CI too?" once when unclear in an interactive session. An unattended request with unclear scope sets up the framework only. Create, Resume, Validate, and Edit choose the operation.
+- **8 Workflows:** Teach Me Testing, Test Design, Framework and CI Setup, Automation (red and expand modes), Test Review, NFR Evidence Audit, Trace, Evaluate. The agent's `AT` and `CI` menu codes remain available for Automate red mode and Framework CI scope.
+- **Framework and CI setup:** One `bmad-testarch-framework` skill handles framework only, CI only, or both. Ask that skill for CI setup, or use the agent's `CI` menu code. TEA infers the scope from your prompt and asks "Do you want CI too?" once when unclear in an interactive session. An unattended request with unclear scope sets up the framework only. Create, Resume, Validate, and Edit choose the operation.
 - **59 Knowledge Fragments:** Distilled expertise on patterns, best practices, Playwright Utils
 - **Quality Standards:** Definition of Done with execution limits (no flaky tests, no hard waits, etc.)
 - **Risk-Based Testing:** P0-P3 matrix for prioritizing test coverage

package/skills/bmad-teach-me-testing/steps-c/step-04-session-03.md

@@ -220,7 +220,7 @@ The prompt determines scope; if CI scope is unclear in an interactive session, a
 Framework scope covers stack selection, fixtures, scaffold, scripts, and the write-time quality hook.
 CI scope covers pipeline generation, quality gates, and evaluation-plan rendering.
 For both, agree the stack, framework, and test commands first. Scaffold and pipeline generation can then run in parallel, with joint validation after both finish. A CI request without a framework offers the framework phase first.
-`bmad-testarch-ci` and `CI` still start CI setup, while `TF` starts framework setup.
+`bmad-testarch-framework` handles CI setup when requested; the agent's `CI` code selects that scope, while `TF` starts framework setup.
 Create starts setup, Validate reports checks without repairing outputs, and Edit revises the selected outputs and checks those changes. Resume continues an interrupted run, whatever its scope and operation.
 
 ### 7. Quiz (3 questions)

package/skills/bmad-teach-me-testing/steps-c/step-04-session-05.md

@@ -71,7 +71,7 @@ Save the updated progress file.
 
 **TDD Red Phase:** Write failing tests FIRST
 
-**Automation red mode:** `/bmad-testarch-atdd` and `AT` select red by default. `/bmad-testarch-automate` also supports an explicit red request.
+**Automation red mode:** Ask `/bmad-testarch-automate` for acceptance tests before implementation, or use the agent's `AT` code to select red.
 
 **Create sequence:**
 
@@ -97,7 +97,7 @@ Save the updated progress file.
 
 **Purpose:** Generate tests for existing features
 
-**Automation expand mode:** `/bmad-testarch-automate` and `TA` select expand by default. An explicit mode in the prompt selects red or expand. Unattended runs keep the invoked command's default when mode is unclear.
+**Automation expand mode:** `/bmad-testarch-automate` and `TA` select expand by default. An explicit mode in the prompt selects red or expand. Unattended runs use expand when mode is unclear.
 
 **Create sequence:**
 

package/skills/bmad-testarch-automate/red/instructions.md

@@ -26,8 +26,7 @@ This workflow uses **step-file architecture**:
 
 This instruction file owns red mode after canonical activation.
 Set `test_mode = red` when a direct runner loads this file without the shared router; keep `{skill-root}` canonical.
-Resolve red customization using `{skill-root}/../bmad-testarch-atdd/customize.toml` and the legacy ATDD overrides.
-When that sibling is absent, merge `{skill-root}/red/customize.toml` with `_bmad/custom/bmad-testarch-atdd.toml` and `.user.toml` manually and retain its workflow block.
+Resolve red customization by merging `{skill-root}/red/customize.toml` with `_bmad/custom/bmad-testarch-atdd.toml` and `.user.toml` manually and retain its workflow block.
 Entry activation and operation routing remain in `{skill-root}/SKILL.md`.
 
 ### 1. Configuration Loading

package/skills/bmad-testarch-automate/resources/test-generation-routing.md

@@ -7,33 +7,31 @@ These are separate from the worker execution mode (`tea_execution_mode`) and the
 ## 1. Choose the Operation and Mode
 
 Keep the original request and supplied files.
-Preserve `test_entry` from a compatibility entry, otherwise use `bmad-testarch-automate`.
+Use `bmad-testarch-automate` as `test_entry`. Preserve a legacy `testEntry` value when resuming an existing checkpoint. An AT menu invocation presets red mode; a single explicit user mode overrides that preset.
 Resolve explicit Create, Resume, Validate or Edit wording first.
 A request to generate tests means Create.
 In a headless or autonomous invocation, an unspecified operation defaults to Create without a menu.
 
 Start with `test_mode_defaulted = false`.
 A single explicit `red mode` or `expand mode` is authoritative.
-Otherwise acceptance tests before implementation, `write acceptance tests`, `acceptance test scaffolds`, ATDD, or the TDD red phase selects red; coverage expansion, tests for existing code, or automation selects expand.
+Otherwise an AT menu invocation selects red. Acceptance tests before implementation, `write acceptance tests`, `acceptance test scaffolds`, ATDD, or the TDD red phase also selects red; coverage expansion, tests for existing code, or automation selects expand.
 Treat the invoked command name as an entry default, separate from the user's task wording: mentioning `/bmad-testarch-automate` in an acceptance-test request cannot count as an expand signal.
-When no task mode signal is present, every run mode defaults to red through `bmad-testarch-atdd` and expand through the canonical entry.
-Interactive AT, TA and slash-command invocations with no task wording use those entry defaults without a mode question.
+When no task mode signal is present, default to expand.
 Ask once which mode to use only when explicit task mode signals conflict in an interactive run, including a request that names both `red mode` and `expand mode`.
-A headless or autonomous run with conflicting signals uses the same historical entry default without a question.
-For either entry-default fallback, set `test_mode_defaulted = true` and state the selected default in the final summary.
-An explicit mode in the user's request overrides the entry default.
+A headless or autonomous run with conflicting signals defaults to expand without a question.
+For a defaulted mode, set `test_mode_defaulted = true` and state the selected default in the final summary.
+An explicit mode in the user's request overrides the default.
 
 The following routing examples apply before customization activation:
 
-| Invocation                      | Task signal                 | Run mode                | Selected mode          | Mode question |
-| ------------------------------- | --------------------------- | ----------------------- | ---------------------- | ------------- |
-| AT or `/bmad-testarch-atdd`     | none                        | interactive             | red (entry default)    | no            |
-| TA or `/bmad-testarch-automate` | none                        | interactive             | expand (entry default) | no            |
-| `/bmad-testarch-automate`       | lets write acceptance tests | interactive or headless | red                    | no            |
-| `/bmad-testarch-automate`       | acceptance test scaffolds   | interactive or headless | red                    | no            |
-| either entry                    | red and expand task signals | interactive             | unresolved             | ask once      |
-| AT or `/bmad-testarch-atdd`     | red and expand task signals | headless                | red (entry default)    | no            |
-| TA or `/bmad-testarch-automate` | red and expand task signals | headless                | expand (entry default) | no            |
+| Invocation               | Task signal                 | Run mode                | Selected mode    | Mode question |
+| ------------------------ | --------------------------- | ----------------------- | ---------------- | ------------- |
+| `bmad-testarch-automate` | none                        | interactive             | expand (default) | no            |
+| `bmad-testarch-automate` | lets write acceptance tests | interactive or headless | red              | no            |
+| `bmad-testarch-automate` | acceptance test scaffolds   | interactive or headless | red              | no            |
+| `bmad-testarch-automate` | red and expand task signals | interactive             | unresolved       | ask once      |
+| `bmad-testarch-automate` | red and expand task signals | headless                | expand (default) | no            |
+| `bmad-tea` AT menu       | none                        | interactive or headless | red              | no            |
 
 For Resume with an exact checkpoint path, resolve it against the project root, verify that it exists and is readable, and retain it as `resume_checkpoint_path`. A missing supplied file stops before activation; do not search for a replacement. The checkpoint path itself is not a new target scope.
 Infer the original mode from that supplied checkpoint's `testMode` or its owning artifact folder: `atdd/` is red and `automate/` is expand; legacy `atdd-checklist-*.md` is red and `automation-summary.md` is expand.
@@ -45,12 +43,10 @@ Do not restart Create or execute a completed generation step on an explicit Resu
 
 ## 2. Choose Exactly One Customization Surface
 
-For red set `workflow-skill-root = {skill-root}/../bmad-testarch-atdd` and `workflow-skill-name = bmad-testarch-atdd`.
+For red set `workflow-skill-root = {skill-root}/red` and `workflow-skill-name = bmad-testarch-atdd` to preserve existing customization filenames.
 For expand set `workflow-skill-root = {skill-root}` and `workflow-skill-name = bmad-testarch-automate`.
-When the sibling red compatibility entry is absent, keep `workflow-skill-name = bmad-testarch-atdd` and use `{skill-root}/red/customize.toml` as the red defaults.
-Resolve the red defaults plus `_bmad/custom/bmad-testarch-atdd.toml` and `.user.toml` manually with the activation merge rules; the resolver's directory-name inference cannot resolve this alias from `red/`.
-Canonical-only installs can therefore run red with existing ATDD overrides.
-Record `workflow_customization_manual = true` for this fallback and retain the resolved workflow block for its terminal hook.
+Resolve `{skill-root}/red/customize.toml` plus `_bmad/custom/bmad-testarch-atdd.toml` and `.user.toml` manually with the activation merge rules; the resolver's directory-name inference cannot resolve this customization namespace from `red/`.
+Record `workflow_customization_manual = true` and retain the resolved workflow block for its terminal hook.
 Keep the resolver's workflow namespace and structural merge rules intact.
 Resolve only the selected surface's defaults, team file and user file.
 Red uses `_bmad/custom/bmad-testarch-atdd.toml` and `.user.toml`; expand uses `_bmad/custom/bmad-testarch-automate.toml` and `.user.toml`.

package/skills/bmad-testarch-evaluate/SKILL.md

@@ -63,7 +63,9 @@ Activation is complete. Begin the workflow below.
 
 ## Workflow
 
-Evaluate is one continuous loop over twelve stages, run inline rather than as separate step files: each stage's craft lives in its own `references/` guide, loaded when that stage is reached. Work under `{tea_evaluations_folder}` unless the adopter names another location. On resume, read the existing inspection record, `evaluation.json`, any `requirements.md`, any `<evaluation-folder>/ci/evaluation-ci-plan.json`, and any `{test_artifacts}/evaluate/<evaluationId>/gap-report.md` before choosing a stage. Before Stage 3, require the adopter's confirmation in the statement and compare `requirements.digest` with eval-quality's `digestBytes` over the committed file; otherwise return to intake. Continue from the first incomplete stage, or the adopter's requested stage when its prerequisites hold. `assets/README.md` says how to fill each template under `assets/`.
+Evaluate is one continuous loop over twelve stages, run inline rather than as separate step files: each stage's craft lives in its own `references/` guide, loaded when that stage is reached. Work under `{tea_evaluations_folder}` unless the adopter names another location. On resume, read the existing inspection record, `evaluation.json`, any `requirements.md`, any `authoring-log.md`, any `<evaluation-folder>/ci/evaluation-ci-plan.json`, and any `{test_artifacts}/evaluate/<evaluationId>/gap-report.md` before choosing a stage. Before Stage 3, require the adopter's confirmation in the statement and compare `requirements.digest` with eval-quality's `digestBytes` over the committed file; otherwise return to intake. Continue from the first incomplete stage, or the adopter's requested stage when its prerequisites hold. `assets/README.md` says how to fill each template under `assets/`.
+
+Read `references/authoring-routing.md` before delegating any authoring work. Use its bounded worker tasks and authoring ledger throughout the loop when the host supports subagents.
 
 Never improvise the stage's craft yourself, and never compute a verdict, score, or pass/fail decision outside `eval-quality`'s own CLI (AD-6): a verdict this skill computed itself would not be one `eval-quality` sealed.
 
@@ -97,7 +99,7 @@ Before the first `tea-evaluate check`, load `references/mutation.md` and author
 
 For an adopter installation, run `npm exec --prefix {tea_evaluations_folder} -- tea-evaluate check --evaluation <evaluation-folder>`, then `npm exec --prefix {tea_evaluations_folder} -- eval-quality compile --in <evaluation-folder>/contract.json --out <evaluation-folder>/compiled-contract.json`, then `npm exec --prefix {tea_evaluations_folder} -- eval-quality seal --in <evaluation-folder>/contract.json --out <evaluation-folder>/sealed-brief.json`. For TeA's own package, run `node cli/evaluate.js check --evaluation <evaluation-folder>`, then `./node_modules/.bin/eval-quality compile --in <evaluation-folder>/contract.json --out <evaluation-folder>/compiled-contract.json`, then `./node_modules/.bin/eval-quality seal --in <evaluation-folder>/contract.json --out <evaluation-folder>/sealed-brief.json` from the repository root. The local CLI and binary use that root's one eval-quality installation. Stop at the first nonzero exit. Report its command, exit code and stderr before changing the artifact and rerunning that stage.
 
-After seal succeeds, copy `assets/evaluation-folder.gitignore` to `<evaluation-folder>/.gitignore` before the first preflight creates `runs/`. For an adopter installation, run `npm exec --prefix {tea_evaluations_folder} -- tea-evaluate preflight --evaluation <evaluation-folder> --partition development`; for TeA's own package, run `node cli/evaluate.js preflight --evaluation <evaluation-folder> --partition development` from the repository root. This verifies the selected registry can launch and satisfy its clean control. The flag is required only when `evaluation.json` declares a `partitionPlan`, and a preflight with no `--partition` over one exits 64. Held-out preflight (`--partition held-out`) runs only after the development review. Stop and report the command, exit code and stderr on failure; complete adapter wiring only after preflight succeeds.
+After seal succeeds, copy `assets/evaluation-folder.gitignore` to `<evaluation-folder>/.gitignore` before the first preflight creates `runs/`. Before a live preflight, follow the Git isolation procedure in `references/run.md`; Git worktrees share refs even when their working files are separate. For an adopter installation, run `npm exec --prefix {tea_evaluations_folder} -- tea-evaluate preflight --evaluation <evaluation-folder> --partition development`; for TeA's own package, run `node cli/evaluate.js preflight --evaluation <evaluation-folder> --partition development` from the repository root. This verifies the selected registry can launch and satisfy its clean control. The flag is required only when `evaluation.json` declares a `partitionPlan`, and a preflight with no `--partition` over one exits 64. Held-out preflight (`--partition held-out`) runs only after the development review. Stop and report the command, exit code and stderr on failure; complete adapter wiring only after preflight succeeds.
 
 ### Stage 7: Evaluator
 
@@ -121,7 +123,7 @@ Interpret a weak result and close the gap. Load `references/gaps.md`.
 
 ### Stage 12: CI
 
-Inspect the adopter's repository, place each check in a tier, write `<evaluation-folder>/ci/evaluation-ci-plan.json` and hand it to `bmad-testarch-framework` with CI setup scope. The `bmad-testarch-ci` compatibility entry remains valid. Load `references/ci.md`.
+Inspect the adopter's repository, place each check in a tier, write `<evaluation-folder>/ci/evaluation-ci-plan.json` and hand it to `bmad-testarch-framework` with CI setup scope. Load `references/ci.md`.
 
 ## On Complete
 

package/skills/bmad-testarch-evaluate/assets/inspection-record.md

@@ -51,6 +51,6 @@ Stage 12 appends this section as each inspection finishes.
 - Release flow: `release.yml` on `v*` tags, with `docs/RELEASING.md` naming the tag as the gate.
 - Risk profile: one `critical` behavior (`contract.json`), about forty model calls per live run, nightly and release accepted and per pull request not (the adopter's answer), a missed defect ships within a day (`docs/RELEASING.md`).
 - Tier exits: `pr` 0; `scheduled` not run, `RESERVATION_MODEL_KEY` is absent on this machine; `release` 2, repair owned by Stage 3.
-- Hand-off status: framework skill invoked with CI scope and Create or Edit, or an open item such as a declined baseline or a missing `bmad-testarch-framework` (with no usable `bmad-testarch-ci` compatibility entry).
+- Hand-off status: framework skill invoked with CI scope and Create or Edit, or an open item such as a declined baseline or a missing `bmad-testarch-framework`.
 
 Replace this worked record with the inspected target's facts and source paths. Record the selected target kind and interface in `evaluation.json` alone.

package/skills/bmad-testarch-evaluate/references/authoring-routing.md

@@ -0,0 +1,31 @@
+# Authoring model routing
+
+Use economical subagents for bounded research and candidate drafting. The parent Test Architect owns requirements confirmation, corpus selection, contract and oracle decisions, artifact writes, every CLI gate, score interpretation, and the final report. A worker's answer is a proposal with file and line evidence. It is never a qualified probe or sealed verdict.
+
+## Select a worker at dispatch time
+
+Inspect the current host's available subagent models immediately before dispatch. On Claude, select the latest available Haiku tier. On Codex, select the latest available Luna tier. Do not put a versioned model ID in the dispatch rule or reuse a recorded ID as the next default. If the host does not expose that tier or an exact resolved model, do the task in the parent session and record the fallback. Do not silently substitute another model tier.
+
+Record the provider, requested tier, exact resolved model, host or CLI version when available, and the selection time in `<evaluation-folder>/authoring-log.md`. The logged versioned ID is an audit observation, not a model pin for later dispatches. Recheck availability for a later session.
+
+This routing applies to the agent **authoring** the evaluation. The target model, system prompt, evaluator framework, rubric judge, decoding settings, and isolation conditions are fixed scored conditions. Keep their recorded snapshots and values identical across clean and mutated arms. A model change to any scored condition needs a new comparable run, never an unrecorded worker substitution.
+
+When the adopter asks for the latest target model or model tier, resolve it from the current provider or host catalog before the first live preflight. Do not inherit a versioned adapter default from an older implementation, reuse a prior evaluation's model ID, or assume the host's configured default is current. Record the requested tier, source and time of resolution, exact ID passed to the target, and the same ID in evaluator conditions. Recheck before a new baseline; if the resolved ID changes, update the condition and repeat check, compile, seal, preflight, run, and score. Historical run records retain their original IDs.
+
+## Delegate bounded tasks
+
+Use at most two read-only workers at once. Give each a disjoint source scope, the confirmed requirements statement, a concrete question, a time bound, and this output shape: `candidate`, `source path and line`, `uncertainty`, and `files inspected`. Good tasks are entry-point inventory, failure-history search, candidate boundary cases, candidate mutation locations, and summaries of public evaluator documentation. Workers may draft a probe or oracle fragment as text, but the parent decides whether it enters the corpus or contract.
+
+When the host supports an isolated worker context, start each task without inheriting the parent conversation. Supply a short task packet with the confirmed requirement, exact source paths, the question, and the output shape above. For a later task, start a fresh bounded worker with a new packet; a long worker history can cost more than the research itself. If the host requires inherited context, keep the worker task narrow and record that constraint. Verify source claims and run the same authoring gates regardless of the context mode.
+
+Keep one writer: the parent. Instruct workers to avoid editing the repository, evaluation folder, policy, or run artifacts; launching targets; running `tea-evaluate` or `eval-quality`; or contacting other workers. Some hosts give subagents writable tools even for a read-only request. Pause parent writes during a worker group. Compare the scoped source and evaluation-file inventory and digests before dispatch and after every worker returns. If files changed, reject the affected drafts, identify the writer, and repair worker-attributed edits before continuing. Never send workers secrets, credentials, private user data, `corpus/held-out/`, a held-out plan, held-out results, or a complete held-out request. When a task cannot be split cleanly, keep it in the parent session.
+
+The parent checks every file and line claim before adopting it. Draft probes still pass `tea-evaluate check`, `eval-quality compile` and `seal`, preflight, scored `run`, and `score` at their normal stages. A cheap worker's confidence or self-reported pass does not replace any gate. If a draft fails a gate, record the failure and repair time in the authoring log.
+
+## Show authoring progress and cost
+
+Start an authoring log in `{test_artifacts}/evaluate/` before Stage 1 inspection, then carry it to `<evaluation-folder>/authoring-log.md` when that folder exists. Record each stage's start and completion time, its artifact paths, and its next gate. For each worker task, record dispatch and completion time, scope, context mode (isolated or inherited), requested tier, resolved model, outcome, retries, parent verification and repair time, and reported input/output tokens or cost when available. Write `unknown` for missing usage. Count parent work separately from worker work. On resume, read the existing log, mark any unfinished worker task interrupted, and continue with new entries rather than replacing prior timings. Keep this log outside `corpus/`, `probes/`, `mutations/`, and `runs/` so it does not alter a corpus digest or sealed run.
+
+For a long target run, use the runtime's progress command when available and report its current phase, completed/planned trials, whole-run elapsed time, and last heartbeat. Report scored trial usage separately from authoring usage; a subtotal is not full-run cost. Continue through `score` before reporting a verdict.
+
+To test savings, compare a parent-only authoring pass with a routed pass using the same confirmed requirements, target revision and model, scoring policy, evaluator conditions, and probe scope. Compare authoring wall time, reported tokens and cost, retries, parent repair time, and gate failures. Compare the resulting clean-control, seeded-defect, and held-out outcomes from eval-quality. Run time and target call cost are separate measurements; authoring routing alone does not shorten a scored target call. Record unknown usage explicitly and make no savings claim from incomplete cost data.

package/skills/bmad-testarch-evaluate/references/ci.md

@@ -1,6 +1,6 @@
 # CI
 
-Run this stage after the evaluation checks clean and a scored run exists (Stages 1 to 11). It writes `<evaluation-folder>/ci/evaluation-ci-plan.json`, the platform-neutral plan that is the only definition of which check runs when and what blocks, then hands the plan to `bmad-testarch-framework` with explicit CI setup scope. The `bmad-testarch-ci` compatibility entry remains valid. Never write a pipeline file here. The plan's schema and placement rules belong to the installed runtime, in `{tea_evaluations_folder}/node_modules/bmad-method-test-architecture-enterprise/cli/lib/evaluate/schemas/evaluation-ci-plan.schema.json` and `{tea_evaluations_folder}/node_modules/bmad-method-test-architecture-enterprise/cli/lib/evaluate/ci-plan.js` (`cli/lib/evaluate/...` from the repository root inside TeA's own package); read them there and copy neither. `npm exec --prefix {tea_evaluations_folder} -- tea-evaluate check --evaluation <evaluation-folder>` reports the plan's findings under the `ci-plan` rule family, so the command that validates the rest of the evaluation validates the plan.
+Run this stage after the evaluation checks clean and a scored run exists (Stages 1 to 11). It writes `<evaluation-folder>/ci/evaluation-ci-plan.json`, the platform-neutral plan that is the only definition of which check runs when and what blocks, then hands the plan to `bmad-testarch-framework` with explicit CI setup scope. Never write a pipeline file here. The plan's schema and placement rules belong to the installed runtime, in `{tea_evaluations_folder}/node_modules/bmad-method-test-architecture-enterprise/cli/lib/evaluate/schemas/evaluation-ci-plan.schema.json` and `{tea_evaluations_folder}/node_modules/bmad-method-test-architecture-enterprise/cli/lib/evaluate/ci-plan.js` (`cli/lib/evaluate/...` from the repository root inside TeA's own package); read them there and copy neither. `npm exec --prefix {tea_evaluations_folder} -- tea-evaluate check --evaluation <evaluation-folder>` reports the plan's findings under the `ci-plan` rule family, so the command that validates the rest of the evaluation validates the plan.
 
 If `check` reports a finding outside the `ci-plan` family, or no scored run exists, name the missing prerequisite and return to its stage before inspecting CI.
 
@@ -48,7 +48,7 @@ The `release` tier is the usual home, since its event is the one that starts the
 Name in the `trigger` of every check on the gating tier each event that starts the gated job's workflow.
 When that workflow also starts on `workflow_dispatch`, as a nightly `deploy.yml` does, list `manual-dispatch` beside `release`, since the CI skill refuses a gate whose job already ran on an event where the tier's evaluation job is skipped.
 The jobs a tier gates are the union of `gates` over the checks the plan places on that tier, so name a job once, on any check of the tier, and a name repeated across the tier's checks is merged.
-`check` accepts a job id and reports any other name under rule `gates`; it cannot tell whether the repository holds that job, which `bmad-testarch-ci` answers when it renders the wait.
+`check` accepts a job id and reports any other name under rule `gates`; it cannot tell whether the repository holds that job, which `bmad-testarch-framework` answers when it renders the wait.
 The wait holds best when the job lives in the workflow file the CI skill edits, which holds the evaluation jobs too: the job then waits through `needs`, and the step refuses the plan when the job already ran in a run where the tier's evaluation job is skipped, such as a deploy on every `push` beside an evaluation job guarded to tags, or when the evaluation job runs on a run the job did not run on before, such as a `workflow_dispatch` the plan adds to a tag-push release file, while a run the render adds that the evaluation job skips is skipped through the wait and is no conflict.
 A job in another workflow file waits through a `workflow_run` trigger, which the step refuses for a pull request tier, for a tier whose evaluation job carries a ref or cron guard, and for a job with its own `needs`, `if:` or ref and event contexts, so hand the CI skill the workflow file that holds the job when you can.
 Leave `gates` out when the inspection found no such job or the adopter declined the gate, and say which in the `reason` of the release entries.
@@ -62,7 +62,7 @@ Place the gameability arm (`gameability`), contract-source freshness (part of `c
 
 Put the live checks where the inspection found a secret and an event: a live `preflight-live` on `merge` when the target needs no secret and the merge flow allows its run time, the held-out partition (`held-out`) on `scheduled` and `release`, judge calibration (`judge-calibration`) on `scheduled` and `release` whenever the contract declares a rubric, and `twin-run` and `strength-comparison` with them. Never place a live check on `pr`. A skill or agent target always needs the runner's model credentials, so its live tiers are `scheduled`, `release` and manual dispatch only; its `trigger` lists `schedule` and `manual-dispatch` for `scheduled` and `release` for `release`, with `manual-dispatch` beside it when the gated workflow starts on `workflow_dispatch`. Without a schedule trigger in the repository, say so in the `reason` and put the set on `release`.
 
-Declare the runner's credential keys as `permittedEnvironmentKeys` through the target's registry `environmentKeys`, which Stage 6 scaffolds and the runtime compiles into the authorization: read them, and add a key name only when a live check needs a credential the registry omits. Keys carry names alone. The plan carries no credential and `bmad-testarch-ci` wires none, so give the adopter the same names as the CI secrets to add for the live tiers.
+Declare the runner's credential keys as `permittedEnvironmentKeys` through the target's registry `environmentKeys`, which Stage 6 scaffolds and the runtime compiles into the authorization: read them, and add a key name only when a live check needs a credential the registry omits. Keys carry names alone. The plan carries no credential and Framework CI setup wires none, so give the adopter the same names as the CI secrets to add for the live tiers.
 
 On Linux the live checks also need the target's registry entry to carry the `egress` authorization for the hosts it reaches.
 A confined Linux target runs in a network namespace with a loopback and nothing else, so read the entry's `egress` and add the model provider's host, port and the addresses the host resolves to now when an item is missing, as the example shows.
@@ -250,7 +250,7 @@ With no accepted baseline, skip the tier runs and record that in the `## CI` sec
 
 ## Hand the plan to framework setup with CI scope
 
-Invoke `bmad-testarch-framework` with explicit CI setup scope and Edit operation on the adopter's pipeline file, naming the plan's path, or Create when the inspection found no pipeline file. The `bmad-testarch-ci` compatibility entry selects the same scope and supports the same operations. Its CI phase detects `ci/evaluation-ci-plan.json` and validates it; the rendering rules belong to `skills/bmad-testarch-framework/ci/steps-c/step-03b-render-evaluation-plans.md` from TEA's repository root. In an installed skill set, resolve it as `{skill-root}/../bmad-testarch-framework/ci/steps-c/step-03b-render-evaluation-plans.md`, where `{skill-root}` is the Evaluate skill root. Setup scope and operation are independent, so this handoff selects CI and preserves an existing framework. CI Edit validates the changed pipeline syntax, injection safety and evaluation-plan rendering/gates; it does not require the adopter's full suite to pass or activate framework hooks. CI Create uses the existing framework contract and its execution gate. Name in the request the concrete event of this repository for each tier it should render, such as `release`: the push of `v*` tags that starts `.github/workflows/release.yml`.
+Invoke `bmad-testarch-framework` with explicit CI setup scope and Edit operation on the adopter's pipeline file, naming the plan's path, or Create when the inspection found no pipeline file. Its CI phase detects `ci/evaluation-ci-plan.json` and validates it; the rendering rules belong to `skills/bmad-testarch-framework/ci/steps-c/step-03b-render-evaluation-plans.md` from TEA's repository root. In an installed skill set, resolve it as `{skill-root}/../bmad-testarch-framework/ci/steps-c/step-03b-render-evaluation-plans.md`, where `{skill-root}` is the Evaluate skill root. Setup scope and operation are independent, so this handoff selects CI and preserves an existing framework. CI Edit validates the changed pipeline syntax, injection safety and evaluation-plan rendering/gates; it does not require the adopter's full suite to pass or activate framework hooks. CI Create uses the existing framework contract and its execution gate. Name in the request the concrete event of this repository for each tier it should render, such as `release`: the push of `v*` tags that starts `.github/workflows/release.yml`.
 That step renders each `gates` entry as a wait of the named job on the evaluation job of the tier, and its summary reports the edit to the job, a name that matches no job and a conflicting gate, so relay that report to the adopter.
 When the plan gates a job, invoke it on the workflow file that holds that job.
-When that skill is not installed, give the adopter the request and the plan's path and record the hand-off as an open item in the inspection record. Stage 12 is complete when the plan passes `check` and the hand-off is made; a declined baseline or a missing `bmad-testarch-framework` (with no usable `bmad-testarch-ci` compatibility entry) stays a named open item in the `## CI` section and does not reopen the stage. Finish with the closing summary: the placement table, the deviations and their reasons, the secrets the live tiers need (the names from `environmentKeys`), the gates adopted, the baseline still to accept, every tier that exited non-zero with the stage that owns its repair, and each publish or deploy job that waits for the evaluation job through `gates`, with every such job the plan leaves ungated and the reason.
+When that skill is not installed, give the adopter the request and the plan's path and record the hand-off as an open item in the inspection record. Stage 12 is complete when the plan passes `check` and the hand-off is made; a declined baseline or a missing `bmad-testarch-framework` stays a named open item in the `## CI` section and does not reopen the stage. Finish with the closing summary: the placement table, the deviations and their reasons, the secrets the live tiers need (the names from `environmentKeys`), the gates adopted, the baseline still to accept, every tier that exited non-zero with the stage that owns its repair, and each publish or deploy job that waits for the evaluation job through `gates`, with every such job the plan leaves ungated and the reason.

package/skills/bmad-testarch-evaluate/references/run.md

@@ -2,6 +2,14 @@
 
 Run from the sealed evaluation folder after its target registry, evaluator, mutations, policy and conditions pass `check`. Save each command, exit status, stderr and resulting artifact path in the run log. Stop the command sequence on a nonzero stage exit; retain diagnostics and route the failure through the gaps guide before retrying. eval-quality alone decides verdict and strength.
 
+## Protect the target's Git state
+
+A `git` workspace makes detached worktrees from `launch.root`. Every worktree of one repository shares its Git common directory, including refs, config and hooks. When confinement is disabled, Evaluate checks that shared state before and after qualification and trials. A branch creation, commit, rebase, fetch, push that updates tracking refs, worktree addition, hook edit, or test that writes refs in another worktree can stop an unconfined run with exit 12 after a costly target call. Separate worktrees alone do not isolate this state.
+
+Before the first live preflight, resolve `launch.root` and run `git -C <launch-root> rev-parse --git-common-dir`. Record the resolved common directory and target commit in the run log. If development or CI-related Git work must continue in the same repository during a long evaluation, use a dedicated clone with its own `.git` directory as `launch.root`. Confirm its common directory differs from the active development repository, update `evaluation.json`, then repeat `check`, `compile`, `seal` and `preflight`. A local clone may share object files but has independent refs; do not add a worktree to the active repository as the substitute.
+
+When the target uses the active repository, reserve a repository-wide Git quiet period before the first live preflight and keep it through `run` and `score`. During that period, do not commit, branch, rebase, fetch, push, add worktrees, edit hooks or config, or run tools that change refs in any worktree sharing its common directory. Read-only status inspection and `tea-evaluate status --follow` can continue. If a run stops for shared Git state, record its command, exit 12 and diagnostic as an infrastructure stop, establish an independent clone or quiet period, and rerun; it has no scored verdict.
+
 ## Install the private latest-spec runtime
 
 In `{tea_evaluations_folder}`, create a private `package.json` with TeA and eval-quality as `devDependencies` at the `latest` spec. The adopter decides whether to track this manifest and its lockfile for reproducibility. Keep the installed versions in the run log. Node >=22.20.0 is required. Install with `npm install --prefix {tea_evaluations_folder}`. Stage 6 installs `assets/evaluation-folder.gitignore` as `<evaluation-folder>/.gitignore` before the first preflight; verify that it still ignores `runs/`, `compiled-contract.json` and `sealed-brief.json` before this run. When `{project-root}` is TeA's own package, invoke `node cli/evaluate.js` from the repository root for TeA commands so the local source is tested. Use the same local engine installation for `eval-quality`.
@@ -56,6 +64,17 @@ npm exec --prefix {tea_evaluations_folder} -- tea-evaluate score --evaluation <e
 
 Use the `invocationId` emitted by `run`; it names `runs/<invocationId>/` and is the value `score --run` accepts. Each trial set has its own `runId`, which is a different identifier. The runtime qualifies mutations against a passing baseline, calibrates any rubric judge, qualifies a sealed-brief agent evaluator on the clean and mutated arms, executes clean and mutated trials through the chosen evaluator, verifies rollback, and seals records and isolation manifests. `score` delegates every probe to eval-quality and persists per-probe diagnostics under `runs/<invocationId>/scores/<scoreInvocationId>/`, plus evidence artifacts, the run-wide `strength-aggregate.json`, `interpretation.json`, `partitions.json` and `gap-view.json`. Preserve both the command exit and each per-probe exit. A clean control should resolve `passed-clean-control` and the seeded defect `caught`; read those states from the evidence artifact. If a development `score` exits 3 with no artifact, read its persisted `score.json`, stdout and stderr diagnostics and route the fault through the gaps guide. For a held-out fault, read only `gap-view.json` and reproduce the class failure in development before inspecting diagnostics.
 
+For a long run, use its invocation ID from another terminal to read progress without disturbing the run:
+
+```sh
+npm exec --prefix {tea_evaluations_folder} -- tea-evaluate status --evaluation <evaluation-folder> --run <invocationId>
+npm exec --prefix {tea_evaluations_folder} -- tea-evaluate status --evaluation <evaluation-folder> --run <invocationId> --follow
+```
+
+Inside TeA, use `node cli/evaluate.js status` with the same arguments. `status` reads the current phase, time spent in that phase, completed and planned trials, whole-run elapsed time, completed phase durations, last heartbeat, and trial usage from the run directory. `--follow` keeps reporting changes until the run ends. The running `run` command also prints periodic heartbeat lines during a long call. If a heartbeat is old, report when it was last seen without claiming the process is still alive. Show the whole-run elapsed time alongside phase timing; the sum of trial durations omits qualification and preflight. Count a shared arm's trials once when reporting totals.
+
+Usage in progress covers scored trials only. Qualification and preflight costs are not fully captured, so full-run cost is unknown even when all trials report. If a trial call lacks complete usage, trial cost is also unknown; the reported amount is a subtotal. An explicit reported zero is a measured zero. Progress carries no verdict and provides no ETA. Continue through `score` to read the evaluation result.
+
 ## Record a before state
 
 A target with known defects fails its clean controls, so `run` stops with exit 11 on the first. Record that starting point with `--before-state` and keep the ordinary run for the fixed target.

package/skills/bmad-testarch-framework/SKILL.md

@@ -68,9 +68,9 @@ Activation is complete. Begin the workflow below.
 
 ## Workflow Architecture
 
-The existing framework steps at the skill root and the CI steps under `ci/` share scope and operation routing. `bmad-testarch-ci` is the compatibility entry point with CI scope preset. Both installed names and the TF/CI menu codes remain available.
+The existing framework steps at the skill root and the CI steps under `ci/` share scope and operation routing. Select CI setup by asking `bmad-testarch-framework` for CI scope.
 
-Create and edit CI phases detect `ci/evaluation-ci-plan.json` and render it through `{skill-root}/ci/steps-c/step-03b-render-evaluation-plans.md`. Evaluate can continue invoking `bmad-testarch-ci` in create or edit mode.
+Create and edit CI phases detect `ci/evaluation-ci-plan.json` and render it through `{skill-root}/ci/steps-c/step-03b-render-evaluation-plans.md`. Evaluate invokes `bmad-testarch-framework` with CI scope in create or edit mode.
 
 ## Initialization Sequence