# Demand and reuse review — 2026-10-13

## Evidence inspected

- [Content-explorer baseline plan](../../content-explorer/workplans/CONTENT-WP-0000-upstream-baseline.md):
  T04 remains `todo`, requesting responsive screenshots and a keyboard walkthrough.
- [Content-explorer scope review](../../content-explorer/history/2026-10-12-1905-scope-against-intent.md):
  no Chrome, Chromium, Firefox or Playwright launcher was found in its workstation
  check; HTTP page-title retrieval did not produce browser evidence. This is the
  consumer's dated observation, not a fresh launcher check in this session.
- [REUSE-IN-0001](../../reuse-surface/intakes/REUSE-IN-0001-headless-browser-runnable-answer.md),
  State Hub intake `01a13530-89a8-77b0-bb95-ef16d74bb29b`: asks for current
  availability and one verified command path with a page, screenshot and keyboard
  interaction. Its owner response assigns browser delivery to rapp-playwright.
- [Existing capability record](../../reuse-surface/registry/capabilities/capability.infotech.headless-browser.md):
  `capability.infotech.headless-browser`, D3/A2/C2/R2, with source reuse in
  whynot-design, coulomb-social, core-hub and frontend-patterns. The planned
  rapp-playwright provider is already named; endpoint and launch are unverified.

The intake originally sought a workstation trial helper and explicitly did not
request a hosted browser farm. The user's direction for this repo adds a reusable
service. Preserve the small trial as the first acceptance gate while resolving
service transport and deployment in a dedicated contract step. Do not substitute
a list of source examples or a local installation recipe for the service goal.

## Demand translated to acceptance

| Consumer need | Provider requirement | Planned proof |
| --- | --- | --- |
| Can a browser execute now? | Preflight distinguishes service availability, client setup and target reachability | Reachable, unavailable, missing-client and unreachable-target outcomes |
| One useful next command | Versioned client/setup and trial path in provider docs and discovery guidance | Independent agent runs without sibling fixture copying |
| Responsive screenshots | Explicit viewports and downloadable artifacts | Desktop and narrow-viewport receipt |
| Keyboard walkthrough | Defined key sequence, focus/action and result assertions | Recorded interaction steps and observed result |
| Trustworthy result | Run identity, versions, target, timestamps, assertions and failure category | Machine-readable receipt for success and failure |
| Honest discovery | Planned versus verified service availability and provider references | Registry update backed by actual consumer receipt |

The provider must document target reachability from the browser runtime. Local
development targets and deployed targets have different network requirements.
No arbitrary tunnel or external-site permission is implied by the service.

The intake's false-`new` verdict and unrelated headless-service matches are
registry relevance issues. They remain reuse-surface's responsibility and do not
justify a duplicate browser capability. A2 means source/library reuse; it does
not mean the caller already has a browser installed.

## Useful sibling structure

| Inspected sibling source | Structure adopted here |
| --- | --- |
| [rapp-postgres intent](../../rapp-postgres/INTENT.md) | Purpose, explicit ownership, consumer boundaries and testable isolation |
| [rapp-issue-core intent](../../rapp-issue-core/INTENT.md) | Reproducible runtime, private consumption, version pinning and rollback |
| [rapp-canned-prompts bootstrap](../../rapp-canned-prompts/workplans/RCP-WP-0001-statehub-bootstrap.md) | Review generated integration files, document actual workflow, seed real workplans |
| [rapp-canned-prompts deployment](../../rapp-canned-prompts/workplans/RCP-WP-0002-first-deployment.md) | Separate declared/deployed/verified states and retain live evidence |
| [rapp-telemetry foundation](../../rapp-telemetry/workplans/RAPP-TELEMETRY-WP-0001-foundation.md) | Staged declaration, admission, runtime proof and owner dependencies; infotech/stack placement |

Workplans use YAML frontmatter, stable repo-prefixed IDs, one fenced `task` block
per task section, explicit dependencies and acceptance evidence. Future delivery
is `proposed`/`todo`; bootstrap completion is not implementation completion.

## Handoff

An initial TAMQ update to reuse-surface was queued as
`m-dccbea4a-ac16-410e-a167-2d2dd8cc27a6`, confirming delivery ownership and planned
status. TAMQ had no active service/endpoints, so that message remains pending.
The final handoff was persisted in State Hub as
`b6a965ed-c02b-49f2-9272-c234e7c8f6a1`, with the registration, published source
and workplan references; see the [receipt](evidence/2026-10-13-reuse-surface-notification.json).
Reuse-surface remains the canonical record maintainer; no duplicate registry
entry is created here. Notification persistence does not imply owner
acknowledgment or a registry edit already performed by that owner.