User Stories · user-stories/platform-user-story-backlog.md Docs Home

Platform User Story Backlog

Purpose

This backlog turns the PRD suite into implementation-ready product stories.

The stories preserve the old Blinkin platform behavior while making the new Hetzner-ready product safer, clearer, and easier to build in small slices.

Source PRDs

PRD 00: ../prds/00-master-platform-prd.md
PRD 01: ../prds/01-auth-tenancy-prd.md
PRD 02: ../prds/02-flow-board-companion-prd.md
PRD 03: ../prds/03-editor-runtime-prd.md
PRD 04: ../prds/04-chat-agents-controls-prd.md
PRD 05: ../prds/05-ai-tools-ingestion-prd.md
PRD 06: ../prds/06-billing-quotas-prd.md
PRD 07: ../prds/07-integrations-media-webhooks-prd.md
PRD 08: ../prds/08-admin-analytics-hetzner-prd.md

Epic 00: Preserve The Legacy Platform

US-CORE-001: Preserve Legacy Capabilities

Story: As a workspace owner, I want the old platform capabilities represented in the new product plan, so that existing workflows do not disappear during the move.

Acceptance criteria:

Given the PRD suite, when I review the platform areas, then auth, flows, Studio, runtime, chat, agents, AI tools, billing, integrations, media, analytics, and operations are all covered.
Given a legacy capability, when it is intentionally not ported, then a retirement decision must exist.

PRD: PRD 00. Evidence: Legacy source coverage in PRD 00 and domain PRDs 01-08.

US-CORE-002: Keep Legacy Sources Read-Only

Story: As an operator, I want the old reference repos to remain read-only, so that preservation work does not accidentally damage legacy evidence.

Acceptance criteria:

Given a future task, when legacy behavior is researched, then standalone reference repos are read but not modified.
Given project instructions, when an agent opens the project, then the blinkin-2-platform hard boundary is visible.

PRD: PRD 00. Evidence: ../../AGENTS.md.

US-CORE-003: Build In Small Verified Slices

Story: As a product designer, I want the platform split into epics and stories, so that implementation can happen in small understandable steps.

Acceptance criteria:

Given the backlog, when a builder chooses a story, then the story has a clear actor, capability, benefit, acceptance criteria, and PRD link.
Given a story is implemented, when it is reviewed, then QA can test external behavior rather than internal code shape.

PRD: PRD 00. Evidence: This backlog.

Epic 01: Auth, Tenancy, Team, And Access

US-AUTH-001: Login To Workspace

Story: As a workspace user, I want to log in and enter the correct workspace, so that I can access my organization's data safely.

Acceptance criteria:

Given a valid user, when login succeeds, then the user lands in a selected workspace.
Given no valid token, when the user opens a protected page, then the user is asked to log in.
Given multiple workspaces, when the user switches workspace, then the current workspace is visible.

PRD: PRD 01. Evidence: Manual 01 and PRD 01.

US-AUTH-002: Invite Team Members

Story: As an org admin, I want to invite teammates with roles, so that the right people can collaborate.

Acceptance criteria:

Given an admin, when they invite an email, then the invite is stored and sent.
Given an invitee, when they accept the invite, then they join the intended workspace.
Given a role, when the user joins, then the role controls access.

PRD: PRD 01. Evidence: Manual 05 and PRD 01.

US-AUTH-003: Manage Roles

Story: As an org admin, I want to manage user roles, so that billing, integrations, publishing, and admin actions stay protected.

Acceptance criteria:

Given a member, when their role changes, then permissions update immediately.
Given a non-admin, when they open restricted settings, then access is denied.
Given an owner, when they manage billing or users, then the action is allowed.

PRD: PRD 01. Evidence: Manual 05 and PRD 01.

US-AUTH-004: External User Access

Story: As a creator, I want external users and groups, so that customer-facing Apps can be shared without giving internal workspace access.

Acceptance criteria:

Given an external user, when assigned to an App, then they can access only that App.
Given a removed assignment, when the external user opens the App, then access is denied.
Given an external session expires, when the user returns, then they must authenticate again.

PRD: PRD 01. Evidence: Manual 05 and PRD 01.

US-AUTH-005: Protect A Published App

Story: As a creator, I want to protect a published App with password, workspace, or external user rules, so that only intended users can enter.

Acceptance criteria:

Given a protected App, when a visitor opens it, then access is checked before runtime data loads.
Given password mode, when the creator saves a password and publishes the App, then the public link shows a password screen before runtime content loads.
Given password mode, when the creator changes or removes the password, then the public link follows the latest saved access rule.
Given password mode, when the visitor enters a wrong password too often, then attempts are rate-limited.
Given public mode, when the visitor opens the link, then no workspace login is required.

PRD: PRD 01 and PRD 02. Evidence: Manual 05.

Epic 02: Flows, Boards, Companions, Forms, And Publishing

US-FLOW-001: Create A Board Or Companion

Story: As a creator, I want to create a board or companion, so that I can start an interactive experience.

Acceptance criteria:

Given create permission, when I create a board or companion, then a draft record exists.
Given the draft opens, when I edit its name and description, then changes are saved.

PRD: PRD 02. Evidence: Manual 03.

US-FLOW-002: Organize Work

Story: As a creator, I want folders, tags, collections, favorites, and recent items, so that large workspaces stay navigable.

Acceptance criteria:

Given many Apps and Boards, when I filter by folder, tag, collection, favorite, or recent, then the correct items appear.
Given an item is moved or tagged, when the list refreshes, then its organization state is preserved.

PRD: PRD 02 and PRD 08. Evidence: PRD 02, PRD 08.

US-FLOW-003: Build A Form Step

Story: As a creator, I want form fields inside a Step, so that runtime users can submit structured data.

Acceptance criteria:

Given a Step, when I add supported fields, then the runtime can render them.
Given required fields, when a user tries to continue without filling them, then validation blocks progression.
Given a submission, when it is saved, then it is tied to flow, form, session, and tenant context.

PRD: PRD 02 and PRD 03. Evidence: Manual 03.

US-FLOW-004: Publish A Stable Version

Story: As a creator, I want to publish a stable App version, so that users do not see draft changes.

Acceptance criteria:

Given draft edits, when I publish, then a new immutable published version is created.
Given more draft edits after publish, when a public user opens the App, then they see the current published version.
Given version history, when I inspect it, then previous published versions are visible.

PRD: PRD 02. Evidence: Manual 03.

US-FLOW-005: Inspect Results

Story: As a creator, I want results and submissions, so that I can understand what users completed and submitted.

Acceptance criteria:

Given users complete a published App, when I open Results, then sessions and submissions are visible.
Given uploaded files exist, when I inspect a submission, then files are linked to the correct session.
Given export is available, when I export, then data respects permissions.

PRD: PRD 02 and PRD 07. Evidence: Manual 03.

Epic 03: Studio Visual Flow And Runtime

US-STUDIO-001: Build A Visual Flow

Story: As a creator, I want to create a visual flow in Studio, so that I can arrange Steps, forms, routing, and AI actions without coding.

Acceptance criteria:

Given Studio, when I create a Visual Flow, then a draft canvas opens.
Given the canvas, when I add Steps and connect them, then the flow path is visible.
Given autosave, when I change the flow, then save status confirms persistence or shows an error.

PRD: PRD 03. Evidence: Manual 08.

US-STUDIO-002: Attach An Agentic App

Story: As a creator, I want to attach an Agentic App inside a Visual Flow, so that one Step can perform an intelligent task.

Acceptance criteria:

Given an Agentic App, when I add it as a Step, then I can map form fields into its inputs.
Given the Agentic App returns output, when the flow continues, then later Steps can display or route from that output.
Given mapping is missing, when I preview, then the platform shows a clear configuration error.

PRD: PRD 03 and PRD 04. Evidence: Manual 08.

US-STUDIO-003: Preview Runtime Behavior

Story: As a creator, I want preview mode, so that I can test the user journey before publishing.

Acceptance criteria:

Given a draft flow, when I preview, then the runtime behaves like a user-facing App.
Given form, media, route, and Agent steps, when I test them, then each success and error state can be seen.

PRD: PRD 03. Evidence: Manual 03 and Manual 08.

US-STUDIO-004: Embed Published Runtime

Story: As a site owner, I want to embed a published App, so that users can complete it on another website.

Acceptance criteria:

Given a published App, when embedding is enabled, then an embed snippet or URL is available.
Given camera, microphone, GPS, or clipboard features, when embedded, then iframe permissions are included only as needed.
Given the runtime fails, when embedded, then a safe fallback is shown.

PRD: PRD 03. Evidence: Manual 03.

Epic 04: Chat, Agents, Controls, Widgets, And Agent Teams

US-AGENT-001: Create An Agent

Story: As an agent builder, I want to create an Agent with instructions, Tools, and knowledge access, so that it can perform a repeatable job.

Acceptance criteria:

Given an Agent draft, when I add name, description, instructions, Tools, and Spaces, then the Agent can be tested.
Given Tool restrictions, when the Agent runs, then it can use only approved Tools.
Given visibility settings, when the Agent is shared, then it appears only to allowed users.

PRD: PRD 04 and PRD 05. Evidence: Manual 02.

US-AGENT-002: Use Chat With Attachments And Voice

Story: As a user, I want chat with text, files, paste, and voice, so that I can work naturally with Agents.

Acceptance criteria:

Given a chat input, when I attach supported files, then upload status is visible.
Given voice input, when I record, then text is produced or a clear error appears.
Given an Agent answer, when it streams, then progress and terminal state are visible.

PRD: PRD 04. Evidence: PRD 04 and Manual 02.

US-AGENT-003: Coordinate A Team Of Agents

Story: As a builder, I want an App to coordinate several Agents, so that complex work can move through planning, execution, review, and approval.

Acceptance criteria:

Given an Agent Team App, when I add Agent Steps, then each Agent has a role and input/output mapping.
Given a failed Agent Step, when I retry, then the workflow can continue.
Given a final output, when approval is required, then it is not published or sent before approval.

PRD: PRD 04. Evidence: Manual 09.

US-AGENT-004: Publish Generated Widgets Safely

Story: As a builder, I want generated controls or widgets to go through review and sandboxed rendering, so that dynamic UI is useful without exposing users to unsafe code.

Acceptance criteria:

Given a generated widget, when it is saved, then it has draft status and validation results.
Given review approves it, when it is published, then a versioned artifact exists.
Given runtime rendering, when the widget loads, then it runs isolated from the main app context.

PRD: PRD 04. Evidence: PRD 04.

US-AGENT-005: View Tool Calls

Story: As a user, I want Tool calls shown as first-class events, so that I understand what an Agent is doing.

Acceptance criteria:

Given an Agent uses a Tool, when the Tool starts, then status is visible.
Given the Tool completes or fails, then result or error is visible.
Given a long-running Tool, when cancellation is allowed, then the user can cancel it.

PRD: PRD 04 and PRD 05. Evidence: PRD 04.

Epic 05: AI Tools, Ingestion, Research, And Knowledge

US-AI-001: Run Deep Research

Story: As a user, I want deep research with progress updates and sources, so that I can trust long-form AI output.

Acceptance criteria:

Given a research request, when it runs, then phases such as planning, searching, analyzing, and final report are streamed.
Given a final report, when I inspect it, then sources or source notes are available.
Given provider failure, when research cannot complete, then a clear error is shown.

PRD: PRD 05. Evidence: PRD 05.

US-AI-002: Ingest Knowledge Sources

Story: As a workspace admin, I want to ingest files, websites, media, and conversations, so that Agents can search workspace knowledge.

Acceptance criteria:

Given a supported source, when it is added to a Space, then processing status is visible.
Given processing completes, when an Agent searches the Space, then the source can be retrieved.
Given duplicate content, when ingested again, then deduplication prevents unnecessary duplicate work.

PRD: PRD 05. Evidence: Manual 04.

US-AI-003: Analyze Documents And Media

Story: As a user, I want OCR, image analysis, video analysis, and audio transcription, so that non-text material becomes usable.

Acceptance criteria:

Given a supported document or media file, when analysis runs, then extracted content is stored with the source.
Given unsupported media, when uploaded, then the user gets a clear reason.
Given analysis cost, when it runs, then usage is recorded.

PRD: PRD 05 and PRD 07. Evidence: Manual 04.

US-AI-004: Track AI Cost And Usage

Story: As an operator, I want every AI and Tool run tracked, so that billing, quotas, and debugging are reliable.

Acceptance criteria:

Given a provider call, when it completes, then provider, model, latency, tokens or units, and estimated cost are recorded.
Given a Tool run fails, when logs are reviewed, then request ID and error reason are present.

PRD: PRD 05 and PRD 06. Evidence: PRD 05 and PRD 06.

Epic 06: Billing, Quotas, Usage, And Wallet

US-BILL-001: Choose And Pay For A Plan

Story: As a workspace owner, I want to choose a plan and complete checkout, so that the workspace can use paid capabilities.

Acceptance criteria:

Given a plan, when checkout succeeds, then subscription state updates.
Given checkout fails, when the user returns, then the platform explains the state.

PRD: PRD 06. Evidence: Manual 07.

US-BILL-002: Enforce Quotas

Story: As an operator, I want quotas enforced safely, so that high-cost operations cannot exceed plan limits.

Acceptance criteria:

Given a quota-limited operation, when usage is below limit, then the operation can run and records usage.
Given usage reaches limit, when the operation is attempted, then it is blocked or warned according to plan rules.
Given concurrent requests, when quota is consumed, then counters remain accurate.

PRD: PRD 06. Evidence: PRD 06.

US-BILL-003: Review Usage

Story: As a workspace owner, I want to review usage, so that I understand costs and plan pressure.

Acceptance criteria:

Given usage exists, when Billing or Usage opens, then relevant usage categories are shown.
Given a limit warning, when the owner opens usage, then the cause is visible.

PRD: PRD 06. Evidence: Manual 07.

US-BILL-004: Process Webhooks Idempotently

Story: As an operator, I want billing webhooks deduplicated, so that retries do not double-process subscription changes.

Acceptance criteria:

Given the same Stripe event is received twice, when the second one arrives, then it is recognized as already processed.
Given processing fails, when Stripe retries, then the event can be safely retried.

PRD: PRD 06. Evidence: PRD 06.

Epic 07: Integrations, Media, Webhooks, Submissions, And Statistics

US-INT-001: Connect Integrations

Story: As an admin, I want to connect external integrations, so that Apps can send or receive data.

Acceptance criteria:

Given integration permission, when I connect a provider, then the connection is available in the workspace.
Given an API response, when integration settings are shown, then sensitive values are redacted.

PRD: PRD 07. Evidence: Manual 06.

US-INT-002: Send Webhook Events

Story: As a developer, I want signed webhook events with delivery logs, so that external systems can trust and debug platform events.

Acceptance criteria:

Given a configured webhook, when a selected event occurs, then a signed request is sent.
Given delivery fails, when retry rules apply, then retries are scheduled and logged.
Given logs are shown, then sensitive payload fields are redacted.

PRD: PRD 07. Evidence: Manual 06.

US-INT-003: Upload Media Safely

Story: As a creator or end user, I want uploads to support common media formats safely, so that flows and submissions can include rich content.

Acceptance criteria:

Given an upload, when file type and size are valid, then upload progress and final asset are shown.
Given an unsafe or invalid file, when uploaded, then it is rejected with a clear message.
Given a public form upload, when it is stored, then it is scoped to the correct tenant, form, and session.

PRD: PRD 07. Evidence: Manual 03, Manual 04, Manual 07.

US-INT-004: View Statistics

Story: As a creator, I want statistics and insights, so that I can understand views, completions, and user behavior.

Acceptance criteria:

Given published App activity, when Insights opens, then views, completions, completion rate, and time range data are visible.
Given a user lacks permission, when they open insights, then access is denied.

PRD: PRD 07 and PRD 08. Evidence: Manual 07 and PRD 08.

Epic 08: Admin, Analytics, Hetzner, And Operations

US-OPS-001: Navigate The Full Platform

Story: As a user, I want a complete navigation model, so that I can access Apps, Boards, Agents, Spaces, Controls, Insights, Integrations, Billing, and Settings.

Acceptance criteria:

Given the user has permission, when they open navigation, then available modules are visible.
Given the user lacks permission, when a restricted module exists, then it is hidden or blocked.

PRD: PRD 08. Evidence: Manual 01.

US-OPS-002: Deploy On Hetzner

Story: As an operator, I want the platform deployable on Hetzner, so that production is repeatable and not tied to a developer laptop.

Acceptance criteria:

Given deployment documentation, when an operator follows it, then services, database, storage, proxy, and TLS are represented.
Given a service starts, when health checks run, then operational status is visible.

PRD: PRD 08. Evidence: PRD 08.

US-OPS-003: Backup And Restore

Story: As an operator, I want backup and restore procedures, so that production data can survive server or storage failure.

Acceptance criteria:

Given production data, when backup runs, then database and object storage are captured.
Given staging, when restore rehearsal runs, then restored data is usable.
Given retention policy, when backups age out, then deletion follows the policy.

PRD: PRD 08. Evidence: PRD 08.

US-OPS-004: Monitor Logs And Health

Story: As an operator, I want logs, metrics, alerts, and request IDs, so that issues can be investigated quickly.

Acceptance criteria:

Given a request, when it crosses services, then a request ID follows it.
Given a service fails, when health checks run, then failure is visible.
Given an error, when logs are reviewed, then tenant, actor where safe, request ID, and error reason are available.

PRD: PRD 08. Evidence: PRD 08.