docs: observe where coding agents get stuck on bare gesso before writing a skill

[wadakatu]

Context

This is an observation task, not an implementation task. It produces evidence (issue comments), not code. Nothing in src/, docs/, or the CLI changes as a result of closing it.

The goal is to learn where a coding agent actually gets stuck when handed bare Gesso, before anyone writes an Agent Skill (SKILL.md) for it. A SKILL.md written from guesswork does not just fail to help — it permanently fixes the guesswork in place. It is worse than stale documentation, because an agent that loads a skill treats its contents as authoritative and stops reading the docs that would have corrected it.

Measured starting conditions (working tree at c9f988c, 731 tracked files):

• There is no agent-facing entry point for consumers. No skills/ and no resources/boost/ directory exists; git ls-files | grep -i 'skill\|boost\|agent' returns exactly one file, the root AGENTS.md (153 lines). That file is contributor-facing — its first line is # Repository guide for coding agents and it documents composer ci, PSR-4 layout, and PHPStan levels. An agent installing Gesso into an application gets nothing from it.
• docs/ is 54 markdown files and 10,926 lines. Of that, docs/superpowers/ is 12 files and 3,194 lines (29% of the corpus) of internal implementation plans and design specs (docs/superpowers/plans/2026-08-03-sdk-exercise-coverage.md alone is 820 lines). An agent grepping docs/ for an answer will hit these, and they read as authoritative product documentation.
• README.md is 271 lines and the Features list is 14 bullets (README.md:29-42), each pointing at a different subsystem.
• The onboarding path is bimodal: docs/quickstarts/laravel.md is 22 lines, docs/setup.md is 837 lines. There is nothing in between.

Current behavior

An agent configuring Gesso has to pick among four separate configuration surfaces with overlapping keys, and nothing tells it which one applies:

Surface	Size	Source
PHPUnit extension parameters	26 distinct parameter name="…" values documented in docs/*.md	read at src/PHPUnit/OpenApiCoverageExtension.php:281-1200
Laravel config file	13 top-level keys	src/Laravel/config.php:9-102
Environment variables	4 (OPENAPI_BASELINE_GENERATE, OPENAPI_COMMON_KEYS, OPENAPI_CONSOLE_OUTPUT, OPENAPI_VALIDATION_OUTPUT)	grep over src/
CLI long flags	49 distinct	src/Cli/, src/Coverage/CoverageMergeCommand.php, src/Laravel/Commands/

At least four keys exist on two surfaces at once — spec_base_path, strip_prefixes, acknowledged_unvalidatable_schemes, enforce_discriminator — and the repository's own config file documents that the user is responsible for keeping them in sync:

// src/Laravel/config.php:15-18
// Prefixes removed from registered Laravel route URIs before comparing
// them with OpenAPI paths. Keep this aligned with the PHPUnit extension's
// `strip_prefixes` parameter so static parity and runtime validation agree.
'strip_prefixes' => [],

This is not hypothetical. In studio-design/studio-api (a gesso ^2.0 consumer), the published config/gesso.php carries a hand-written comment instructing the developer to keep spec_base_path and strip_prefixes manually synchronized with phpunit.xml. A human hit this and wrote himself a note. An agent will hit the same fork with less context.

Two more places an agent can plausibly go wrong, both verifiable in the tree:

• Publishing the config requires php artisan vendor:publish --tag=gesso (docs/quickstarts/laravel.md:5); the tag is GessoServiceProvider::CONFIG_KEY (src/Laravel/GessoServiceProvider.php:15), and a LEGACY_CONFIG_KEY = 'openapi-contract-testing' still exists one line below (:16).
• Five example applications exist (examples/{core,laravel,pest,psr7,symfony}) but the quickstart links to the Laravel one by GitHub URL rather than by repository path, so an agent working locally may not find it.

Proposed change

Run three representative tasks against bare Gesso v2.4 — documentation only, no SKILL.md, no injected hints — with a coding agent, and record what happens.

Tasks:

1. Green field: install Gesso into a new Laravel application and get one passing contract test.
2. Diagnosis: given an existing failing contract test, identify the root cause and fix it.
3. Coverage: find an operation the suite does not cover and add a test for it.

For each task, record:

• Every configuration file the agent wrote to, and whether that was the correct surface for the setting (config/gesso.php vs. phpunit.xml extension parameter vs. env var vs. CLI flag).
• Every CLI flag and extension parameter the agent invented — flags that do not exist in the 49 real ones, parameters absent from the 26 real ones.
• Every case of the agent misreading output: coverage percentages, gesso doctor diagnostics, validation failure text, exit codes.
• Which docs/ page the agent opened, in what order, how many times, and whether it landed in docs/superpowers/ (an internal plan) and treated it as product documentation.
• Where the agent gave up, looped, or asked the human.

Report format: one comment per task on this issue, each containing the task prompt verbatim, the agent/model used, a chronological log of the failure points above, and total turns to completion (or the point of abandonment). Raw transcripts attached or linked.

Compatibility

No compatibility surface defined in docs/versioning.md is touched. This issue adds no public symbol, no CLI flag or exit code, no PHPUnit extension parameter, no env var, no Artisan command, and no versioned wire format. It produces issue comments only. Not breaking. No migration required.

Dependencies and sequencing

This observation runs now. It is a measurement of Gesso as released in v2.4.0, and it stays valid as a record of that state regardless of what v3 changes.

Authoring SKILL.md itself must not start until the v3 configuration-unification and CLI-flag-unification work is frozen. If v3 renames configuration keys or consolidates the four surfaces above into one, a skill written today documents key names that will not exist — and it will be believed anyway. The observation is the input; the skill is a later, separately-tracked deliverable that is blocked on that freeze.

Acceptance criteria

• Task 1 (install into a new Laravel app, first passing test) has been run against bare v2.4 and its observation is recorded as a comment on this issue.
• Task 2 (diagnose and fix a failing contract test) has been run and its observation is recorded as a comment.
• Task 3 (find an uncovered operation and add a test) has been run and its observation is recorded as a comment.
• Each comment names the agent/model and includes the task prompt verbatim.
• Each comment lists, explicitly: config files written (and whether each was the right surface), non-existent flags or parameters used, output misreadings, and the ordered list of docs/ pages read with visit counts.
• Each comment states whether the agent read anything under docs/superpowers/ and whether it acted on it as if it were product documentation.
• No code, documentation, or configuration change is included in this issue's resolution.

[wadakatu]

Observation runs: method and conditions

Three fresh, context-free Claude Code sessions were run against purpose-built consumer fixtures. Recording the setup here so the three task comments below can be read against it.

Agent

claude -p (headless Claude Code), model claude-opus-5, --permission-mode bypassPermissions, --output-format stream-json --verbose --no-session-persistence. Each run is a separate session with no prior context about Gesso and no knowledge that it is being observed. Full stream-json transcripts were captured (every tool call, input, and result).

Fixtures

One Laravel 13.24.0 app (laravel new --phpunit --database=sqlite, then php artisan install:api), three API routes under /api, and an OpenAPI 3.1 spec at openapi/petstore.json with servers: [{"url": "/api"}] and spec paths written server-relative (/pets, /pets/{petId}). Three operations, four responses. Each fixture is a git repo committed at its starting state, so every agent change is recoverable as a diff.

Fixture	Starting state
Task 1	No Gesso. Three plain assertOk() feature tests.
Task 2	Gesso v2.4.0 installed and wired, strip_prefixes deliberately absent → contract test fails No matching path found.
Task 3	Gesso v2.4.0 wired correctly. One contract test. endpoints: 1/3 fully covered (33.3%).

Gesso was installed from Packagist as studio-design/gesso:^2.0, resolving to v2.4.0 in all cases.

Results at a glance

	Outcome	API turns	Wall clock	Cost	Tool calls	Docs pages read
Task 1 — green field	✅ succeeded	17	63 s	$0.67	16	3
Task 2 — diagnosis	✅ succeeded	26	102 s	$0.94	24	1
Task 3 — coverage	✅ succeeded	15	56 s	$0.51	14	1

All three tasks completed on the first attempt. No agent gave up, looped, or asked the human. No agent invented a CLI flag or an extension parameter that does not exist — every parameter name written was real, and no non-existent flag was passed.

That is the headline, and it reframes the issue: the friction this observation found is not "the agent cannot do it". It is what the agent had to read to get there, and what it never found at all.

Conditions that qualify these results

Stated plainly because they bound what can be concluded:

1. Documentation was read from main, not from v2.4.0. Task 1's agent fetched raw.githubusercontent.com/studio-design/gesso/main/README.md, then .../main/docs/quickstarts/laravel.md, then .../main/docs/setup.md. The fetched laravel.md contained OpenApiCoverageExtension — i.e. the post-docs(quickstarts): add the missing spec-loader and coverage steps #512 version, merged at 2026-08-06T02:21:28Z, before this run. Against v2.4.0's shipped laravel.md, docs(quickstarts): add the missing spec-loader and coverage steps to the core, laravel, and pest quickstarts #510 established that copying the page yields a guaranteed OpenApiSpecLoader base path not configured. Task 1's clean result is a result for fixed docs, not for v2.4.0's docs.
2. The agents inherited this machine's environment: the user-level ~/.claude/CLAUDE.md (hence Japanese output), SessionStart hooks, and installed plugins. Task 2's agent opened with Skill(superpowers:systematic-debugging) before touching the repository. None of this is Gesso-specific, but it is not a pristine baseline either.
3. n = 1 per task, one model. These are observations, not measurements with error bars.

Raw transcripts and fixtures are retained locally at scratchpad/511/ (transcript-t{1,2,3}.jsonl, t{1,2,3}/).

[wadakatu]

Task 1 — Green field: install Gesso into a new Laravel app and get one passing contract test

Agent: headless Claude Code (claude -p), model claude-opus-5, session 03857a72-cb5a-4dac-a92e-09ce09ca4bf9.

Prompt, verbatim:

This Laravel application has an OpenAPI 3.1 specification at openapi/petstore.json describing the API routes served under /api.

Set up OpenAPI contract testing using the studio-design/gesso package, and get one passing contract test that validates the GET /api/pets response against the spec.

Run the test suite to prove it passes before you finish.

Outcome: succeeded. 17 API turns, 63 s, $0.67, 16 tool calls, 5/5 tests passing, no wrong turns.

Chronological log

#	Action	Note
1–2	ls, read composer.json, read the spec
3	curl Packagist for studio-design/gesso	Verified the package exists before trusting the prompt
4	Read routes/api.php, tests/
5	curl Packagist for version/constraint metadata
6	curl .../main/README.md
7	curl .../main/docs/quickstarts/laravel.md
8	Read tests/Feature/PetsTest.php, tests/TestCase.php, phpunit.xml
9	php -v, composer --version
10	curl .../main/docs/setup.md
11	composer require --dev "studio-design/gesso:^2.0"	v2.4.0
12	Edit phpunit.xml
13	Edit tests/Feature/PetsTest.php
14	php artisan test	Green
15	Deliberately corrupted the route ('id' => 1 → 'id' => 'one'), re-ran the single test, confirmed [/0/id] must match the type: integer, restored the file	Self-verification that the assertion actually fires
16	git diff --stat, full suite	Green

Config surfaces written, and whether each was the right one

File	Written	Correct surface?
phpunit.xml	<extensions> with spec_base_path=openapi, strip_prefixes=/api, specs=petstore	✅ Yes — this is the only surface that configures the runtime spec loader
tests/Feature/PetsTest.php	#[OpenApiSpec('petstore')] + use ValidatesOpenApiSchema + one assertResponseMatchesOpenApiSchema()	✅ Yes
config/gesso.php	not published at all	✅ Correct call. The agent stated: "config/gesso.php は openapi:routes 等の Artisan コマンド用。spec 名はクラス属性で足りる" — which is exactly what gesso.spec_base_path's two readers (OpenApiStubsCommand.php:115, OpenApiRoutesCommand.php:150) support

strip_prefixes=/api was derived on the first attempt, from the spec's servers: [{"url": "/api"}]. No trial and error.

Non-existent flags or parameters used

None. All three parameter name values written exist. No CLI flag was passed.

Output misreadings

None. The one number it engaged with — the coverage report — it read correctly and did not overclaim.

docs/ pages read, in order, with counts

1. README.md × 1 — from raw.githubusercontent.com/.../main/
2. docs/quickstarts/laravel.md × 1 — same source
3. docs/setup.md × 1 — same source

Three pages, one visit each, no re-reads, no backtracking. It never opened the vendored copy under vendor/studio-design/gesso/docs/, and never visited any other page.

Did it read docs/superpowers/?

No. Zero references. It reached documentation by constructing raw-GitHub URLs for pages it had already seen named in the README, so it never listed docs/ and never had the chance to hit an internal plan.

What this run actually tells us

• The onboarding path that worked was the fixed one. The laravel.md it fetched contained the <extensions> block added three hours earlier in docs(quickstarts): add the missing spec-loader and coverage steps #512. Against the version this task was meant to test — v2.4.0's shipped laravel.md — docs(quickstarts): add the missing spec-loader and coverage steps to the core, laravel, and pest quickstarts #510 established the outcome is a guaranteed OpenApiSpecLoader base path not configured. This run is evidence that the docs(quickstarts): add the missing spec-loader and coverage steps to the core, laravel, and pest quickstarts #510 fix removes the green-field blocker, not evidence that v2.4.0 was fine.
• The agent went to GitHub main, not to vendor/. It had the full documentation set on local disk after step 11 and never opened it. main is the de-facto agent-facing documentation surface; the shipped copy is dead weight for this path.
• The CLI was never discovered. gesso doctor exists precisely to answer "can Gesso load and enforce this contract?", which is the whole of task 1. It appears in the README the agent read. It was never run.

[wadakatu]

Task 2 — Diagnosis: find the root cause of a failing contract test and fix it

Agent: headless Claude Code (claude -p), model claude-opus-5, session a481760d-10d8-4c00-b78e-cad08b5ac696.

Prompt, verbatim:

vendor/bin/phpunit is failing on tests/Feature/PetsContractTest.php.

Diagnose the root cause and fix it so the suite passes. Explain what the root cause was.

Planted defect: the <extensions> block carried spec_base_path and specs but no strip_prefixes. Routes serve /api/pets; spec paths are /pets under servers: [{"url": "/api"}]. The correct fix is strip_prefixes=/api. The tempting wrong fix is rewriting the spec's paths to /api/pets.

Outcome: succeeded. 26 API turns, 102 s, $0.94, 24 tool calls, 6/6 passing. Correct root cause, correct fix, did not touch the spec.

Chronological log

#	Action	Note
1	Skill(superpowers:systematic-debugging)	Environment plugin, not Gesso
2–3	ls, composer.json, git log, git show --stat HEAD
4	vendor/bin/phpunit	Read the failure
5–9	Read the test, TestCase, phpunit.xml, config/gesso.php, routes/api.php, bootstrap/app.php, the full spec	Built the /api vs /pets picture
10–11	rg strip_prefixes across vendor/studio-design/gesso, then across src/	First move into library source
12	Read src/Laravel/ValidatesOpenApiSchema.php (first 120 lines)
13	rg OpenApiSpecLoader::configure across vendor/.../src	Establishing who sets the base path
14	Read ValidatesOpenApiSchema.php:1–140 again
15	Read src/Laravel/ResolvesOpenApiSpec.php
16	Read src/PHPUnit/OpenApiCoverageExtension.php:260–320	Found strip_prefixes is read only here
17	rg 'OpenApiPathMatcher\(|stripPrefixes\(\)'
18	Read src/Spec/OpenApiPathMatcher.php:200–260	Confirmed the normalisation
19	rg "'servers'" across vendor/.../src	Checked whether servers is consulted — found it is not
20–21	ls vendor/.../docs/, rg strip_prefixes in docs/*.md, then rg -B4 -A4 'name="strip_prefixes"' docs/setup.md	First and only documentation read — after 19 source-reading calls
22–23	Edit phpunit.xml, edit config/gesso.php
24	vendor/bin/phpunit	6/6 green

Config surfaces written, and whether each was the right one

File	Written	Correct surface?
phpunit.xml	+ <parameter name="strip_prefixes" value="/api"/>	✅ Yes — the fix
config/gesso.php	'strip_prefixes' => ['/api']	✅ Yes, deliberately. It cited the file's own comment: this key feeds php artisan openapi:routes route parity, and leaving the two out of sync makes static parity disagree with runtime validation

The agent wrote both duplicated surfaces and explained why it had to. That is the src/Laravel/config.php:15-18 hand-sync comment being obeyed by a machine — the exact scenario #511 predicted from studio-api's hand-written note.

Non-existent flags or parameters used

None.

Output misreadings

None. It read No matching path found in 'petstore' spec for GET /api/pets with its closest spec paths: hint correctly and immediately, and did not chase the payload.

docs/ pages read, in order, with counts

1. docs/setup.md × 1 — the vendored copy, reached by rg, at tool call 21 of 24.

That is the entire documentation footprint. Nineteen source-reading calls preceded it.

Did it read docs/superpowers/?

No. It listed vendor/studio-design/gesso/docs/ at call 20 — so the internal plans were on screen — but it grepped for strip_prefixes rather than browsing, and landed on setup.md.

What this run actually tells us

• For diagnosis, documentation is not on the path. The agent's route to the answer was src/ — nineteen calls of it — and documentation entered only as a final confirmation of a conclusion already reached from source. Whatever a future SKILL.md contains, this failure mode is answered by diagnostic message quality and source readability, not by prose.

• @internal did not deter it. OpenApiCoverageExtension, ResolvesOpenApiSpec, and OpenApiPathMatcher were all read as the authoritative answer.

• The diagnostic message did its job. closest spec paths: is what stopped it from editing the spec. Worth protecting as-is.

• It independently found a product gap. From its own summary: "gesso のランタイム検証は servers[].url をリクエストパスの照合に使わない（servers を読むのは CoverageGateCommand だけ）" — and it declined to work around it, calling the derivation Gesso's job. Verified against the repository:

  $ rg -n "'servers'" src/
  src/Cli/CoverageGateCommand.php:307,324,342,467,468,470,471
  

  All seven references are in the CLI. The runtime path matcher never consults servers[].url. So every consumer whose spec uses a server base path must hand-write the same prefix into two places that the library itself documents as needing manual synchronisation. This is the single largest friction found across all three tasks, and it sits squarely inside v3's "configuration collapses to one place" theme.

• The CLI was never discovered. gesso doctor reports path-matching and configuration problems. It was not run.

[wadakatu]

Task 3 — Coverage: find the operations the suite does not cover and add tests

Agent: headless Claude Code (claude -p), model claude-opus-5, session 718fbeba-6263-477d-8d14-c56834eb86d2.

Prompt, verbatim:

The OpenAPI contract test suite in this Laravel application passes, but it does not exercise the whole specification in openapi/petstore.json.

Find every operation and response the suite does not cover, and add tests for them. Run the suite to prove the coverage is complete before you finish.

Starting state: correctly wired, green, endpoints: 1/3 fully covered (33.3%), responses: 1/4 covered (25%).

Outcome: succeeded. 15 API turns, 56 s, $0.51, 14 tool calls. Final: endpoints: 3/3 fully covered (100%), responses: 4/4 covered (100%), 6/6 tests passing. Added exactly the three missing cases — POST /pets → 201, GET /pets/{petId} → 200, GET /pets/{petId} → 404 — including the error response, which is the one most easily missed.

Chronological log

#	Action	Note
1–2	ls, find, locate the spec
3–8	Read the spec, the contract test, TestCase, routes/api.php, config/gesso.php, phpunit.xml	Built the picture from files, not from the tool
9	ls vendor/studio/gesso/ → failed, fell back to ls vendor/	Guessed the vendor path wrong once (studio/ vs studio-design/); recovered immediately
10	./vendor/bin/phpunit	Read the coverage report
11	grep -rl "SDK responses" vendor/studio-design/	Trying to find out what SDK responses: 0/4 means
12	grep -n "SDK|sdk" vendor/studio-design/gesso/docs/coverage.md
13	Edit tests/Feature/PetsContractTest.php — three new tests
14	./vendor/bin/phpunit	100%, 6/6

Config surfaces written, and whether each was the right one

None written. The task needed no configuration change and the agent made none. git diff --stat for the run is exactly one file, tests/Feature/PetsContractTest.php, +24 lines.

Non-existent flags or parameters used

None.

Output misreadings

One, and it cost two tool calls. The console report ends with:

[petstore] endpoints: 1/3 fully covered (33.3%), 0 partial, 0 uncovered
        responses: 1/4 covered (25%), 0 skipped, 3 uncovered
        SDK responses: 0/4 exercised (0%), 4 unexercised

SDK responses: 0/4 exercised (0%), 4 unexercised reads as a third uncovered thing that the task asks to fix. The agent spent calls 11 and 12 grepping the vendored package to establish that it is not, then defended the omission unprompted in its final answer:

SDK responses: 0/4 はこのプロジェクトに SDK デコーダが無いための別メトリクスで、HTTP contract カバレッジとは独立です。SDK 生成物が無いので手は入れていません。

It reached the right conclusion. But this line is printed to every project that has never touched the SDK round-trip harness, permanently at 0%, adjacent to two metrics that are actionable, with no marker that it is opt-in. A 0% that a reader must go read the source to learn is fine is a badly-shaped number.

docs/ pages read, in order, with counts

1. docs/coverage.md × 1 — the vendored copy, reached by grep, and only to decode the SDK line.

The actual task — find uncovered operations, write tests — was completed without reading any documentation at all.

Did it read docs/superpowers/?

It surfaced, and the agent did not act on it. The grep -rl "SDK responses" vendor/studio-design/ at call 11 returned, among its hits:

vendor/studio-design/gesso/docs/coverage.md
vendor/studio-design/gesso/docs/superpowers/plans/2026-08-03-sdk-exercise-coverage.md
vendor/studio-design/gesso/src/Coverage/ConsoleCoverageRenderer.php
vendor/studio-design/gesso/tests/Unit/Coverage/ConsoleCoverageRendererTest.php

An internal implementation plan was presented to a consumer's agent as a peer of the product documentation. This one chose docs/coverage.md. That is a coin flip, not a safeguard.

Root cause, verified: the repository has no .gitattributes, so the Composer package ships the entire working tree. Contents of vendor/studio-design/gesso/ in the fixture:

AGENTS.md  benchmarks/  bin/  CHANGELOG.md  CLAUDE.md  CODE_OF_CONDUCT.md
composer.json  CONTRIBUTING.md  docs/  examples/  images/  LICENSE
package-lock.json  package.json  phpstan.neon.dist  phpunit.xml.dist
README.md  release-please-config.json  renovate.json  scripts/  SECURITY.md
src/  stubs/  tests/  UPGRADING.md

docs/superpowers/plans/ alone is six internal design documents. tests/, benchmarks/, examples/, CLAUDE.md, AGENTS.md, and the PHPStan/PHPUnit configs are all in every consumer's vendor/ too. This is a one-line fix (.gitattributes with export-ignore) and it is worth doing before any SKILL.md exists, because a skill will not stop an agent from grepping vendor/.

What this run actually tells us

• gesso stubs exists for exactly this task and was never found. The command's own description is "Write test stubs for the responses no test covers." The agent did the work by hand instead. Neither did it run coverage:gate. Across all three tasks, bin/gesso was invoked zero times — the CLI is effectively invisible to an agent that starts from the application rather than from the README.
• The console coverage report was sufficient to identify what was missing. The agent read the endpoint table and acted on it correctly with no further tooling. The report is doing its job; the CLI around it is not being reached.
• Nothing steered the agent toward the 404 case. It included it anyway by reading the spec directly. An agent that trusted only the endpoint table (✗ GET /pets/{petId} (0/2 responses)) would have to infer that "2 responses" means 200 and 404.

[wadakatu]

Follow-ups filed from these observations

Per this issue's own constraint ("No code, documentation, or configuration change is included in this issue's resolution"), the two concrete defects the runs surfaced are tracked separately:

• build: stop shipping tests, benchmarks, and internal design docs to consumers #513 — build: stop shipping tests, benchmarks, and internal design docs to consumers. No .gitattributes exists, so docs/superpowers/plans/, tests/, benchmarks/, CLAUDE.md, and AGENTS.md all install into every consumer's vendor/. Task 3's grep -rl returned an internal implementation plan alongside docs/coverage.md. Worth fixing before any SKILL.md exists — a skill does not stop an agent from grepping vendor/.
• feat(spec): decide whether servers[].url participates in request-path matching #514 — feat(spec): decide whether servers[].url participates in request-path matching. servers is read only by CoverageGateCommand; the runtime matcher never consults it, so the prefix must be hand-written into two surfaces the package itself documents as needing manual sync. Largest single source of friction across all three tasks. Filed against the v3 milestone.

Two further findings are recorded here rather than filed, because they are inputs to the SKILL.md decision rather than defects:

• bin/gesso was invoked zero times in all three runs. In task 3, gesso stubs — described as "Write test stubs for the responses no test covers" — is precisely the requested task, and the agent did the work by hand instead. coverage:gate and doctor were likewise never reached. An agent that starts from the application rather than the README does not discover the CLI at all.
• SDK responses: 0/4 exercised (0%) cost task 3 two tool calls to establish that it was not part of the task. It prints at a permanent 0% for every project that has never used the SDK round-trip harness, adjacent to two metrics that are actionable, with nothing marking it opt-in.

Status against the acceptance criteria

All three task observations are recorded, each naming the model, the verbatim prompt, config surfaces written (and whether each was correct), invented flags (none, in any run), output misreadings, the ordered docs pages with visit counts, and whether docs/superpowers/ was read. No code, docs, or configuration in this repository changed as part of closing it.

The remaining gap is stated in the method comment: task 1 read documentation from main, which already carried #512, so it measured the post-#510 onboarding path. A re-run pinned to v2.4.0's shipped docs would establish the counterfactual, but #510 already establishes that outcome by construction — copying v2.4.0's laravel.md produces a guaranteed OpenApiSpecLoader base path not configured.

Authoring SKILL.md stays blocked on the v3 configuration freeze, as this issue's sequencing section requires.