Current project status#
This documentation covers the supported code in the current repository checkout. Architecture documents and decision issues also describe intended capabilities; an accepted direction is not evidence that its implementation exists.
Supported workflows#
| Area | Available now | Starting point |
|---|---|---|
| Reporting contracts | Compose adapter registrations, resolve settings and coordinate developer-owned reporting sessions | Configure reporting |
| Portable reports | Create, validate, revise, remove evidence, sanitize, export and import bug reports | First bug report |
| Test catalogs | Discover Markdown definitions and hierarchical sections, validate inheritance, select tests | Author test plans |
| Test execution | Coordinate runtime callbacks or a filesystem bridge, hooks, progress, cancellation and explicit retries | First test run |
| Test reporting | Retain attempts/comments, aggregate results, promote bugs, render reviewed HTML reports | Review results |
| Maintained examples | React buggy/fixed profile scenario and plain-HTML host | Sample site |
These are checkout/build workflows. These pages do not assume a published npm release or a hosted documentation service.
Experimental demonstrations#
The reporting/theming prototype demonstrates presentation, recording controls, evidence review, and local drafts. Recording and evidence are simulated. Draft/theme state is in memory; full reload resets it. It does not collect real screen/audio/video evidence, upload files, persist drafts, or submit tracker tickets.
The plain-HTML page has an empty labelled mount region for future embedding. It demonstrates an independent host, not a finished launcher/widget. Capture and embedding supply portable adapter interfaces; developer-supplied implementations run through the reporting session lifecycle. Built-in live collectors and a universal launcher remain separate work.
The illustrative report example exercises real report-processing APIs with authored fixture data. It is not a record of a browser session.
Runtime-dependent capabilities#
Execution needs a real host runtime with fresh agents, durable evidence, and isolated browser contexts. A new tab sharing a profile is insufficient. Current T3 collaborative preview tabs share browser storage and do not satisfy that isolation requirement; they remain useful for reviewing repository changes. Runtime requirements explains the distinction.
Deferred work#
Live capture, universal embedding, supplied Jira/Linear authentication and transport, ticket-link replay, automatic regression-test generation, and server/storage behavior remain separate product work. The provider interface is a seam for host adapters, not a shipped tracker integration.
Documentation hosting, publication/access, repository visibility, releases, and deployment are also deferred. The site can be built and previewed locally. Product decisions remain in the issue tracker.