rapp-playwright/docs/demand-and-reuse.md

Demand and reuse review — 2026-10-13

Evidence inspected

• Content-explorer baseline plan: T04 remains todo, requesting responsive screenshots and a keyboard walkthrough.
• Content-explorer scope review: 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, 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: 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	Purpose, explicit ownership, consumer boundaries and testable isolation
rapp-issue-core intent	Reproducible runtime, private consumption, version pinning and rollback
rapp-canned-prompts bootstrap	Review generated integration files, document actual workflow, seed real workplans
rapp-canned-prompts deployment	Separate declared/deployed/verified states and retain live evidence
rapp-telemetry foundation	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. 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.