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

Compare commits

merge into: anodyine/relayview-site:main
anodyine/relayview-site:main anodyine/relayview-site:ISSUE-3
...
pull from: anodyine/relayview-site:ISSUE-3
anodyine/relayview-site:ISSUE-3 anodyine/relayview-site:main
2 Commits
Author SHA1 Message Date
admin 1ef8d60bfc Show idea to issue as the workflow entry 2026-10-14 21:25:29 -04:00
admin b7c18dec2f Draft public claims and simulated demo brief 2026-10-14 20:38:46 -04:00
2 changed files with 91 additions and 0 deletions
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
+88
View File
@@ -0,0 +1,88 @@
# 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 `f7c0394`. 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 turn an idea into reviewable coding work and supervise it. The story begins with a conversation: the person explains a goal, discusses scope and tradeoffs with RelayView, reviews proposed issues, and chooses what enters the work queue. An implementation planner can then work from a selected issue. The visitor's problem spans both shaping the work and following it across specialized roles, handoffs, checks, and a final human decision without treating an agent's completion report as proof. Issue publication through the product is planned, not current behavior.
**Hero copy**
> See every handoff.
>
> Start with a conversation about what you want to build. RelayView is being built to help shape that work into reviewable issues, then make the handoffs visible as each selected issue moves through implementation planning, checks, and review. 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 | “Before coding begins, an idea needs a clear scope and an issue someone can review. Afterward, the work crosses planning, implementation, checks, and review. A final answer alone does not show how the task was framed, what changed, what was checked, or what still needs your judgment.” Avoid measured time, quality, or cost savings. | C2, C12, C13 |
| Workflow | “Discuss a goal, review proposed issues, and choose what enters the queue. Follow a selected issue through implementation planning, handoffs, candidate checks, and human review.” Mark issue drafting/publication as planned and the entire illustration as simulated. Do not imply RelayView currently picks issues autonomously or show future Code-review or static-analysis steps as current behavior. | C2, C3, C8, C12, C13 |
| 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. |
| C12 | **Verified current behavior with limits:** a person can start a planner-led task and discuss the request in Planner Chat before asking for implementation planning. A task can also be linked to an existing, owner-verified Gitea issue. | `docs/authoritative/production-task-onboarding.md` and `browser-task-session-ui.md`. Current discussion does not itself create an issue or start implementation. |
| C13 | **Planned capability:** the person discusses and revises an epic or issues, reviews the exact drafts and destination, explicitly authorizes publication, and later starts issue-backed implementation planning. | Private issue #353 and `docs/speculative/relayview-benchmark-completion-order.md`; ADR 0012 selects issue drafting as MVP direction. The current owner-mediated adapter reports issue creation as unsupported. Do not promise autonomous backlog pickup or automatic publication. |
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 conversation about a sample reading-list app. The visitor describes the goal “Help me find unread articles with a keyboard.” RelayView proposes a small issue such as “Add a keyboard-accessible unread filter,” which the fictional user reviews before publication. The sample app, item names, issue number, file names, and check outputs must be invented for this demo; they are not excerpts from RelayView runs or benchmarks. The planned issue-publication transition must carry its own “Planned capability” label in addition to the persistent simulation label.
| Stage | Visitor sees | Handoff or check | Status boundary |
| --- | --- | --- | --- |
| 1. Discuss the goal | A short synthetic user/RelayView exchange clarifies the reading-list problem, scope, and acceptance criteria. | Human → planning conversation. | Simulated illustration of current planner-led discussion; no live task created. |
| 2. Review proposed issues | One fictional issue draft shows title, scope, and acceptance criteria; the user can inspect it and choose “Approve in illustration” or “Revise in illustration.” | Conversation → human-reviewed issue proposal. | **Planned capability.** Current product does not create issues through this path. |
| 3. Queue and select | A fictional published issue appears in a sample queue, then a person selects it for implementation planning. | Approved issue → issue-backed implementation task. | **Planned publication.** The sample queue is local fixture data; no Gitea write or autonomous pickup. |
| 4. Implementation Plan | A short fictional Plan scopes the selected issue and its acceptance checks. | Implementation Planner → Implementer handoff, shown as a fixed Plan. | Illustrative product pattern; not a live Plan. |
| 5. Implementation | A small synthetic change summary and sample candidate identifier. | Implementer → checks handoff. | Do not render real code, prompts, tool traces, or run output. |
| 6. 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. |
| 7. 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. |
| 8. 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.