Resolving Stack Commands

---
name: resolving-stack-commands
description: Use whenever an agent must run a toolchain command (build, test, mutation) and needs the concrete invocation. Resolves build/test/mutation commands from the detected stack via the `quality-gates-<tech>` adapters so no agent hardcodes `dotnet test`, `dotnet build`, or any toolchain command. Loaded by acceptance-designer and software-engineer.
---

# Resolving Stack Commands (stack-agnostic)

The single place that maps a repository's stack to its concrete toolchain
commands (build, test, mutation). No agent and no workflow step may hardcode a
command (`dotnet test`, `dotnet build`, `mvn test`, `pytest`, ...). They resolve
it here instead.

## Why this exists

The pipeline must run with .NET today and other stacks tomorrow (Java planned,
not yet supported). If each agent embeds `dotnet test`, swapping or adding a
stack means editing every agent. Centralizing the mapping keeps agents
tech-agnostic: they say "build the solution" / "run the test suite" / "run
mutation", this skill says how.

## Detection → adapter

Detect the stack from markers at the repo root, then resolve the concrete
commands from the matching `quality-gates-<tech>` adapter (the adapter owns the
build / test / mutation commands and their evidence mapping):

| Stack | Detection markers | Adapter | Status |
|---|---|---|---|
| .NET | `*.sln`, `*.slnx`, `**/*.csproj`, `Directory.Packages.props` | [quality-gates-dotnet](../quality-gates-dotnet/SKILL.md) (`dotnet build` / `dotnet test` / `dotnet stryker`) | supported |
| Node JavaScript, TAP | Selected `package.json` declares installed StrykerJS core + TAP 9.6.1; explicit checked-in core/boundary configs use `testRunner: 'tap'` | [quality-gates-javascript](../quality-gates-javascript/SKILL.md): checked-in scripts/native Node tests and sequential mutation runner | narrow support; no G11 coverage enforcement |
| Node JavaScript without StrykerJS core + TAP 9.6.1 | A `package.json` that the row above does not match (Stryker absent, other runner or version) | No matching supported adapter | NOT SUPPORTED — a missing mutation runner is a blocker, never an exemption |
| Frontend, TypeScript, other JavaScript mutation runners | Browser/TS build or non-TAP Stryker runner | No matching supported adapter | NOT SUPPORTED |
| Java | `pom.xml`, `build.gradle`, `build.gradle.kts` | _(quality-gates-java not yet provided)_ | NOT SUPPORTED |

Every `package.json` and every .NET solution in the repository is a stack to resolve. If multiple stacks coexist, run each adapter and aggregate results; an unsupported one blocks the whole delivery, even when another stack passes.

## Unsupported stack → stop, never guess

If the detected stack has no `quality-gates-<tech>` adapter, STOP and emit a
structured blocker. Never invent a command:

```yaml
status: blocked
type: unsupported_stack
message: No quality-gates adapter for the detected stack
context:
  stack: java
  markers:
    - pom.xml
  needed: test
```

## Stack-commands file (resolve once per pipeline)

Inside a SKRAFT pipeline, resolved commands live in one file every later agent reads:
`.copilot-tracking/skraft-plans/{projectSlug}/details/{date}/stack-commands.md`.

- **Read before resolving.** When the handoff block lists the file, take the commands
  from it and do not run the detection above.
- **Resolve only when** the file is absent, a command in it fails to start or to build
  (a test that fails on its assertion is not a command failure), or the stack markers
  changed since the recorded revision.
- **Write:** the first agent that resolves writes the whole file; a later agent that
  re-resolves rewrites only the failing rows and the revision line.
- Never record credentials, tokens or environment-variable values in it.

```markdown
<!-- markdownlint-disable-file -->
# Stack commands
- Stack: {stack} — adapter `quality-gates-{tech}`
- Resolved at: {output of git rev-parse HEAD}

| Purpose | Command | Working directory |
|---|---|---|
| build | {command} | {dir} |
| test — full suite | {command} | {dir} |
| test — one test (filter placeholder `{TestName}`) | {command} | {dir} |
| mutation — core (adapter script) | {command} | {dir} |
| mutation — boundary (adapter script) | {command} | {dir} |
```

## Contract for callers

- Resolve the command (build / test / mutation) from the matching `quality-gates-<tech>` adapter; do not embed it in workflow steps.
- Run it, then assert on its output (build succeeds, RED on a business assertion, GREEN gate, mutation score, etc.).
- Adding a stack = add a `quality-gates-<tech>` adapter and a row here, with zero edits to agents.