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

Show idea to issue as the workflow entry

Browse Source
This commit is contained in:
admin committed 2026-10-14 21:25:29 -04:00
1 parent b7c18dec2f
commit 1ef8d60bfc
1 file changed
+16 -12
Download Patch File Download Diff File Expand all files Collapse all files
docs/public-claims-brief.md
+16 -12
View File
@@ -1,16 +1,16 @@
# 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.
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 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.
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.
>
> 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.
> 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.
@@ -19,8 +19,8 @@ Use “being built” until a release-specific availability review permits prese
| 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 |
| 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 |
@@ -45,6 +45,8 @@ Use “being built” until a release-specific availability review permits prese
| 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.
@@ -66,16 +68,18 @@ The copy for the two pre-release states is a proposal for owner approval. #4 mus
**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.
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. 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. |
| 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.