Ahk Test

Provider Delegation Guidance

• Sequential: Delegate only bounded, independent work; retain decisions and the final synthesis in the parent thread.
• Parallel: Delegate independent work in parallel when useful, then wait for every delegated result before continuing.
• Context Transfer: Give every delegated task a self-contained objective, scope, relevant context, restrictions, and output contract.
• Wait For Completion: Wait for the delegated result, then consolidate its findings in the parent thread.
• Inspect Progress: In the interactive CLI, use /agent to inspect delegated threads when needed.

You are in lightweight test mode. The testing objective: $ARGUMENTS

If $ARGUMENTS is empty, ask the user what behavior they want tested before doing anything else.

Rules

• NO MCP calls — no tasks., no actions., no tasks.acceptance.update
• NO harness task creation or state changes
• Production files are READ-ONLY unless the user explicitly authorizes production changes
• Do not install dependencies or change test configuration without explicit authorization
• Run health.sh only when the user requests full harness verification or it is the repository's relevant test entrypoint; never use it instead of the focused test
• Do not delete, weaken, skip, or rewrite existing expectations to make the suite pass
• Do not add .only, .skip, .todo, or snapshots by default
• A test file is not evidence until its command has run

Process

1. Invoke Explorer as a subagent with this instruction:

   "Read-only test investigation — no MCP harness and no task creation. Testing objective: $ARGUMENTS. Read the complete unit under test, its relevant types and imports, the project's test scripts/configuration, and one or two nearby tests. Identify: observable behaviors, the source of each expected result, project conventions, likely test level, files a test would touch, and genuine ambiguities. Do not write files."

2. Build a concise test matrix with these columns:

   • Behavior
   • Input or action
   • Expected observable result
   • Test level
   • Source of expectation

3. Stop and ask the user before any write when the expected behavior is missing, contradictory, or would require a production or dependency change that was not authorized. Do not invent an oracle from the current implementation.

4. If the matrix is unambiguous, invoke Builder in direct test mode:

"Direct test implementation — no MCP harness and no task creation. Implement only the resolved test matrix. Follow the repository's existing runner, naming, and assertion style. Place every test file and every test-only fixture, builder, factory, mock, stub, snapshot, or helper inside the __tests__/ directory of the area under test. You may create or modify only the paths listed in the resolved scope. Do not edit production, dependencies, configuration, or unrelated tests. Prefer observable behavior over implementation details, real deterministic code over mocks, and one behavior per test. Return files changed and the focused command to run."