coulomb/rapp-playwright
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Establish Playwright service intent and staged delivery workplans

Browse source 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a13590-a16f-7f60-be60-fd71627bc99d
This commit is contained in:
tegwick 2026-10-13 16:12:17 +02:00
parent 91897ffbf4
commit 6f9576d5b6
13 changed files with 835 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

66
docs/demand-and-reuse.md Normal file
View file

@ -0,0 +1,66 @@
# 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. The final handoff will carry the registration and workplan references.
Reuse-surface remains the canonical record maintainer; no duplicate registry
entry is created here.