runneth-status

Visual status page

Reviewed, customer-safe status and operating guidance for Runneth.

This repo has two related jobs:

• The visual status page shows a richer capability/status map for CSMs, product, and operators.
• Agent Builder can inject selected notices into Runneth turns when a notice should change what Runneth says or does.

Do not turn the status page into a raw bug list. Add an item only when it changes customer guidance, support triage, product expectation-setting, or Runneth behavior.

Files

• primitives.json: the richer status-page product map.
• status-page-notices.json: the single source of truth for the visual status page and the Morning/EOD Slack posts. Carries Runneth-use rules, explicit workarounds, resolution flags, and the optional releaseNote.
• limitations.json: reserved for durable limitations or guidance.
• app-agent-prompt.md: prompt for the Runneth app agent that updates the visual status page.
• skills/runneth-status-update/SKILL.md: skill for rewriting rough status requests into reviewed status-page notices.

Status Page Areas

The visual page should keep these top-level areas:

• runneth: broad Runneth platform/runtime behavior.
• chat: Motion chat UI, live conversation startup, streaming, idle wake, and chat continuity.
• brain: saved rules, files, templates, skills, and routed context.
• conversations: conversation history, recall, sidebar visibility, and direct conversation access.
• slack: Slack reading, posting, setup, reconnect, and install flows.
• google_drive: Google Drive and Google file access.
• notion: Notion access.
• integrations: parent category for native OAuth, Data access, Pipedream/long-tail integrations, and secrets/API keys.
• data_access: Motion data, external endpoints, CLI-backed data access, workspace context, brand context, workspace goal, spend threshold, Meta data, TikTok data, creative summaries, transcripts, reports, and Inspo.
• apps: openable pages, dashboards, widgets, previews, and app refreshes.
• routines: scheduled, recurring, monitored, refresh, or later work.

Slack, Google Drive, and Notion should stay as standalone cards because they are native OAuth integrations customers ask about directly. They can also appear under the Integrations parent category.

Runneth Use

status-page-notices.json separates status-page visibility from what Runneth should actually do with a notice:

• releaseNote: an optional top-of-page note for the current planned release window and operational context.
• resolutionOptions: the supported resolution flag types for notice cards.
• use_when_relevant: Runneth should use the guidance whenever the user's request touches this area.
• only_when_asked: Runneth should use the guidance only when the user asks about or reports that specific issue.
• status_page_only: the notice is visible to CSMs/product/operators, but should not be injected into Runneth by default.

Examples:

• Routines setup degraded: use_when_relevant, because any request to create later, scheduled, recurring, or monitored work needs a different response.
• Missing conversations from the sidebar: status_page_only, because CSMs should know it exists, but Runneth should not proactively mention it in normal conversations.
• Slack file uploads degraded: use_when_relevant, because affected upload requests need clear guidance when Slack-side retries are unreliable.

Every status-page notice should also include a workaround. If there is no workaround, say that clearly and provide the safest alternate path. Make it concrete enough to show on the visual page and safe enough for Runneth to repeat to a customer when the notice is injected.

Use pinned: true when a notice should stay at the top of the visual status page. Pinning is only a display signal for the app. It does not make Runneth inject the notice, and it does not change runnethUse.

Use customerBanner: true when an in-product banner is live for all customers on this issue (an urgent, customer-affecting bug). The status page renders a distinct Customer banner live flag on the card. This is a display signal only: it does not change runnethUse and does not decide whether Runneth injects the notice. "Banner" here means the banner customers see in the Motion product UI, not the status page's own refresh banner.

Use resolution on every notice for the small visual flag on the status page:

• confirmed_next_release: show a checkmark-style "Next release" flag. This means the fix is confirmed for the next planned release, but the notice is still active until the release ships.
• working_toward_next_release: show a subtle in-progress flag. This means the team is working toward the next planned release, but it is not marked ready yet.
• in_progress: show a subtle in-progress flag. This means the team is working on it, but it is not tied to the next planned release.
• notice_only: show a neutral notice flag. This means the notice is guidance/status visibility and does not imply a release fix.

Use examples on every status-page notice. Leave it as an empty array when there is no example yet. When an example exists, include a short label, a link, the specific observed response or symptom, and what to look for so the visual page can show the evidence without forcing someone to open the thread first.

Prompt Injection Feed (retired)

The standalone status.json prompt-injection feed has been retired. status-page-notices.json is now the single source of truth for the visual status page and the Morning/EOD Slack posts, and it already carries the Runneth-facing fields (runnethTrigger, runnethGuidance, supportGuidance, resolution, pinned, runnethUse). Runneth reads status-page-notices.json when a request touches a known issue, so there is no separate Builder-injected feed to maintain.

When someone asks to post or update a status notice, use skills/runneth-status-update/SKILL.md to rewrite the request into the notice shape before editing the JSON.

Data Access Detail

Data access should be specific. Do not describe it only as "Motion CLI."

The status page should call out:

• Meta data: own-account Meta performance, creative rows, metrics, creative summaries, transcripts, copy/headline/landing-page groupings, metric references, and filter references.
• TikTok data: own-account TikTok performance, grouped metrics, associated creative details, and TikTok-specific query shape.
• Creative summaries: generated creative understanding used for analysis and strategy.
• Transcripts: spoken-word/script data where the CLI supports it, especially Meta video transcript pulls.
• Data endpoints: workspace goal, spend threshold, brand context, metric references, filter references, and custom conversion metrics.
• Reports: saved Motion reports, marked as coming soon until the reports endpoint is live.
• Inspo: competitor and organic inspiration, marked as coming soon.

Current source-of-truth notes:

• Own-account Meta creative work should route through motion meta insights. Meta data includes performance metrics, creative rows, creative summaries, transcripts when requested, and grouping by creative/copy/headline/landing page.
• TikTok-specific performance should route through motion tiktok insights. TikTok data includes TikTok performance metrics and associated creative details, but it is not the same transcript or creative-summary surface as Meta.
• Saved Motion reports and report configurations are coming soon; do not present the reports endpoint as live until it ships.
• Workspace goal should trigger for broad Meta asks like best, worst, what is working, what to scale, goal/conversion setup, or attribution-window questions.
• Spend threshold should only trigger when the user asks for significant-spend-only data, spend cutoffs, or threshold config.
• Own-brand strategy context should route through motion brand-context --data-query.
• Inspo brands, unique creatives, boards, board items, creators, organic TikTok posts, and organic TikTok keyword steering are coming soon with matching Runneth guidance in the next release.
• For Inspo guidance, be clear about direct query paths versus pull-then-filter routes: competitor ads and saved board items support specific filters, known creators can be looked up by name or handle, organic TikTok can pull the current recommendation feed or an exact creator handle, and organic keywords guide future feed recommendations. Broad creator/category/engagement filtering and live organic TikTok topic search are still being expanded; if Runneth pulls a limited page and filters it after retrieval, it should say that is not the same as direct search and may take a while.

Refresh Timestamp (last-refreshed banner)

The visual status page shows a "last refreshed" banner that reads the top-level updatedAt of status-page-notices.json.

Any change to the status page must move that banner:

• Set the top-level updatedAt to the real current UTC time. Do not hardcode, round, or guess it.
• Set the top-level updatedAt on every data file you edit (primitives.json, limitations.json, status-page-notices.json).
• Always bump status-page-notices.json.updatedAt even when only another file (for example primitives.json) changed, since that field drives the banner.

Review Rules

Keep customer-facing fields safe. Do not include secrets, customer names, private channel IDs, internal Slack thread links, private Linear links, production traces, credentials, or customer-specific incident notes while this repo is public.

Changes are reviewed through GitHub like normal code: edit the JSON or prompt file in a pull request, review the wording, merge to main, and let the status page or Agent Builder consume the updated raw feed.