tegwick
4efabd60ec
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a13590-a16f-7f60-be60-fd71627bc99d
70 lines
4.9 KiB
Markdown
70 lines
4.9 KiB
Markdown
# 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.
|