anodyine/relayview-site
1
0 Fork 0
Code Issues 6 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Draft public claims and simulated demo brief

Browse Source
This commit is contained in:
admin committed 2026-10-14 20:38:46 -04:00
1 parent c8410f6d5d
commit b7c18dec2f
2 files changed
+87
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

README.md
+3
View File
@@ -6,3 +6,6 @@ orchestration implementation and the demo makes no model calls.
The launch plan is tracked in [the site epic](https://tea.kyle-merritt.com/anodyine/relayview-site/issues/2).
The site and demo are planned; this repository does not claim they are live.
The [public claims and experience brief](docs/public-claims-brief.md) is a
candidate for owner approval before the page and demo are implemented.
docs/public-claims-brief.md
+84
View File
@@ -0,0 +1,84 @@
# RelayView public site: claims and experience brief
Status: **candidate copy and demo scope for owner approval; not approved for publication**. Prepared for [site issue #3](https://tea.kyle-merritt.com/anodyine/relayview-site/issues/3) on 2026-10-14 against private RelayView commit `f5a4ad5`. The site and demo are not live. Recheck the private product sources and the publication review before #4 or #5 uses this brief.
## Audience and promise
The primary visitor is an individual software developer or technical lead evaluating how to supervise coding-agent work. Their problem is following a request across specialized roles, handoffs, checks, and a final human decision without treating an agent's completion report as proof.
**Hero copy**
> See every handoff.
>
> RelayView is being built to make agent-driven software work visible from task planning through implementation, checks, and review. Follow the work, inspect the evidence, and keep the final decision with a person.
Use “being built” until a release-specific availability review permits present-tense product copy. Do not promise that every action is verified or that all checks and review roles in the product direction are implemented.
## Page sequence and copy boundaries
| Section | Candidate visitor-facing copy or constraint | Claim IDs |
| --- | --- | --- |
| Hero | Use the hero above. Label the page as a product preview before public release. Primary action: “Explore the simulated workflow” only after #5 ships; before then, show “Demo coming soon” as text. | C1, C2 |
| Problem | “A coding task can cross planning, implementation, checks, and review. A final answer alone does not show what changed, what was checked, or what still needs your judgment.” Avoid measured time, quality, or cost savings. | C2 |
| Workflow | “See the task, its handoffs, the candidate under review, and the evidence tied to that candidate.” Add “The illustrated workflow below is simulated” beside any demo entry. Do not show future Code-review or static-analysis steps as current product behavior. | C2, C3, C8 |
| Community | “RelayView Community is planned as a complete, free, proprietary product for one human operator, including use at work on commercial projects.” One person may operate multiple agents, projects, and machines. State release availability separately. | C4 |
| Trust and portability | “RelayView has selected a direction to publish independently buildable security-enforcement modules and versioned workflow-data contracts. These artifacts are planned and are not available yet.” A concise expandable explanation may name the four module families below. Do not use “open source RelayView” or imply an open trust repository exists. | C5, C6 |
| Teams | “RelayView Teams is the planned offering for multiple people and organizations, adding shared governance, fleet operation, maintained deployment, enterprise integrations, and support.” Do not imply a running Teams service or a price. | C7 |
| Integrations | “Initial Community work focuses on maintained integrations with supported free-software systems and portable user-supplied skills. Additional integration and public adapter support remain delivery work.” Do not show provider logos, a supported-integration list, or a public SDK claim until release evidence is approved. | C9 |
| Proof | Until public evidence is reviewed, omit performance numbers, customer logos, testimonials, certifications, uptime, and security guarantees. Show only a clearly labeled synthetic demo, if approved. | C8, C10 |
| Calls to action | Keep distinct Community and Teams paths and their current states as specified below. Never render an inert action as a button. | C11 |
## Claim register
“Verified current” means supported by current authoritative product documentation, **not** generally available to customers. “Selected direction” is an accepted product boundary. “Planned” means implementation or publication evidence is still missing. These source paths are in the private `../relayview` checkout and are for editorial review; do not copy their contents or private implementation into this repository.
| ID | Claim and status | Current source and publication limit |
| --- | --- | --- |
| C1 | **Verified current brand:** “See every handoff.” | `docs/authoritative/brand.md` and private `README.md`. Tagline promises visibility, not verification of every action. |
| C2 | **Verified current behavior, preview wording:** task, session, Plan, implementation, review, and Git views expose durable handoffs. | `docs/authoritative/brand.md`, `architecture.md`, and `browser-task-session-ui.md`. Publish only a customer-level description; do not expose control protocols or screenshots from private runs. |
| C3 | **Verified current behavior with limits:** a Planner and Implementer work in separate sessions; a Plan reviewer examines an exact candidate and evidence. Human completion remains a separate gate. | `docs/authoritative/architecture.md`, `automatic-plan-v1-handoff.md`, and `review-roles-and-artifacts.md`. Do not rename the Plan reviewer “Code reviewer,” claim independent static analysis is live, or imply an agent can accept work for a person. |
| C4 | **Selected direction, not a released license:** complete free proprietary Community for one human operator, including workplace/commercial-project use. | `docs/authoritative/product-editions.md` and `brand.md`. Final terms and distribution have not shipped; do not offer a download or call it a trial, open source, open core, or feature-limited. |
| C5 | **Selected direction; artifacts planned:** open trust modules at non-bypassable enforcement seams. Families: sandbox/process/filesystem confinement; credential custody and bounded authenticated operations; command/network-egress enforcement; independent audit and artifact-integrity verification. | `docs/authoritative/product-editions.md`, ADR 0017, and `docs/speculative/relayview-open-trust-modules.md`. None is published. No claim of current independent buildability, substitution, or assurance. |
| C6 | **Selected direction; contracts planned:** versioned workflow-data and export contracts for durable events, Plans/handoffs, evidence and acceptance, interchange, and complete export. | `docs/authoritative/product-editions.md` and ADR 0017. No public interoperability package or conformance proof has shipped. |
| C7 | **Commercial intent; capability planned:** Teams adds multi-human identity/governance, fleet operation, maintained deployment, enterprise integrations, and support. | `docs/authoritative/product-editions.md`; `docs/speculative/relayview-teams-business-plan.md`. Do not imply availability, a service, price, or contractual support. |
| C8 | **Planned site artifact:** a scripted browser illustration uses original synthetic fixtures and deterministic state. | Public site [#5](https://tea.kyle-merritt.com/anodyine/relayview-site/issues/5). It is a simulation, not proof that a depicted product stage is shipped. |
| C9 | **Selected MVP direction:** first-party free-software integrations and portable user-supplied skills; public adapter development deferred. | `docs/authoritative/product-editions.md`, ADR 0012, and `docs/speculative/community-mvp-capability-acceptance.md`. Name no available integration without release evidence. |
| C10 | **Unverified claims excluded:** performance, customers, certifications, uptime, broad security assurance, trademark registration, and integration availability. | No approved publication evidence in the reviewed sources. Owner must supply and approve specific proof before adding any of these. |
| C11 | **Planned journeys:** Community adoption and Teams contact need separate honest destinations. | Public site #3 and private #277. No approved public download, signup, contact endpoint, or Teams service was identified. |
The proprietary boundary applies to both editions: the orchestration engine, role prompts, context construction, handoff and correction strategies, model routing and ranking, and evaluation-derived mechanisms are not public artifacts. Do not reproduce them in copy, fixtures, images, JavaScript, metadata, or source maps.
### Evidence required before upgrading a planned claim
For **each** open trust module, require links to the exact corresponding source and revision, license, dependency and toolchain identities, build instructions, tests and conformance fixtures, policy and interface definitions, artifact-correspondence evidence, compatibility and update rules, operator substitution instructions, supported platforms, and assurance limits. A public wrapper or source file alone does not qualify. For workflow-data/export availability, require versioned specifications, semantics, compatibility rules, conformance fixtures, and independent validation evidence. Reclassify only the particular shipped artifact; do not upgrade the whole family by association.
## Two visitor journeys and current CTA states
| Journey | Owner and destination | Before release | After an approved destination exists |
| --- | --- | --- | --- |
| Community adoption | Product owner; a future verified Community release/download destination, exact URL pending owner review. | Show “Community release information coming soon” as plain text. No download, signup, or waitlist button. | Link to the exact approved release and terms, then verify the installation path. |
| Teams contact | Product owner; a future verified contact destination, exact URL/address pending owner review. | Show “Teams inquiries: contact route coming soon” as plain text. No form or mail link. | Link to the owner-approved contact route and verify receipt/privacy handling. |
| Demo exploration | Site maintainer; on-page demo route owned by #5. | “Demo coming soon” as plain text. | Link only after the deterministic demo is built, labeled, and checked. |
The copy for the two pre-release states is a proposal for owner approval. #4 must not invent an email address, form, release link, service, or download to make the CTAs appear active.
## Simulated task-to-review story for #5
**Persistent label:** “Simulated workflow — fictional task and evidence. No agents or product backend are running.” Place it adjacent to the demo title and keep a visible “Simulated” label on each stage and evidence panel. The browser may advance only through local deterministic fixture state. No model call, private backend connection, or real repository operation is allowed.
Use an original fictional task: “Add a keyboard-accessible filter to a sample reading list.” The sample app, item names, file names, and check outputs must be invented for this demo; they are not excerpts from RelayView runs or benchmarks.
| Stage | Visitor sees | Handoff or check | Status boundary |
| --- | --- | --- | --- |
| 1. Request | Fictional request, acceptance criteria, and a “Start illustration” control. | Human supplies the task. | Simulated; no live task created. |
| 2. Plan | A short fictional Plan with scope and acceptance checks. | Planner → Implementer handoff, shown as a fixed Plan. | Illustrative product pattern; not a live Plan. |
| 3. Implementation | A small synthetic change summary and sample candidate identifier. | Implementer → checks handoff. | Do not render real code, prompts, tool traces, or run output. |
| 4. Checks | Two fictional checks, for example keyboard navigation and filter behavior, with explicit “sample result” labels. | Checks bind to the sample candidate; a changed candidate would require fresh checks. | No assurance or performance claim. |
| 5. Review | A fictional Plan-review finding or pass with a clearly bounded scope, followed by a human review card. | Automated Plan review → human decision. | Do not depict a separate Code reviewer or independent static analysis as live. |
| 6. Human decision | “Accept” and “Request changes” controls change only local demo state. Explain that only a person can accept the real work. | Human acceptance point. | The demo never merges, publishes, or sends anything. |
Include a deterministic alternate path with one failed sample check and a correction that invalidates the earlier sample evidence. Provide an empty-evidence explanation rather than a fabricated pass. The demo must work by keyboard, preserve focus, honor reduced motion, and fit mobile through desktop; #5 records those checks.
## Publication gate
Before #4 or #5 implements visitor-facing copy, the owner must approve the **exact** pre-release wording, the selected demo stages, each disclosure classification, and any image/fixture scope. The separate private publication review records the detail-level disclosure decision. If approval or source evidence is absent, keep the affected claim or demo detail out of the published site. Recheck source status immediately before deployment under #6.