Incident Triage
Incident Triage packages a small incident register without a dedicated host page,
renderer component or application-specific runtime branch. Its source is
apps/incident-triage/app.toml; the native record remains in
crates/shared/schema/app-incident-triage/src/lib.rs.
Supported workflow
The Incidents page starts empty. Create an incident with a title, severity and
owner; impact and summary are optional text. Open a row to edit its full record.
Severity is free text, with sev1 through sev4 suggested by the form.
New incidents have status open. Resolve and reopen update only status, so
they preserve title, owner, severity, impact and summary. The list hides resolved
records by default; open Filters and uncheck Hide resolved incidents to
open them again.
Long impact and summary values remain intact when selecting and editing a row.
The app uses the same durable entity queue and explicit installation grants as the collaborative board. An online, visible installation requests bounded foreground snapshots with a minimum 15-second interval and failure backoff. Reconnect and settled actions also request refresh. Unsaved form values and the selected detail are preserved; reopen a record from the refreshed list to see another client's changes.
One package, existing host
| Package declaration | Shared implementation |
|---|---|
Native Incident schema and seven signed fields | Descriptor validation, typed CBOR records and per-field merge |
incident-list pipeline | Authorized dataset read, complete-row filters, deterministic sort and projection |
| Form and list bindings | Rust/WASM binding interpreter and the generic Vue renderer |
| Create/edit/resolve/reopen actions | Durable entity operations, optimistic projection and explicit field masks |
Fixed all collection group | The same grouped collection hydration used by board comments |
foreground_snapshot_v1 | The installed host's bounded foreground refresh scheduler |
The release requests read and write access only to app_incident_triage.Incident
and invocation only of incident-list. Timeline, hypothesis and next-action
records have existing native examples but are outside this release. No network,
secret, notification or infrastructure capability is requested.
Author, build and install
rac app validate apps/incident-triage/app.toml
rac app build apps/incident-triage/app.toml
rac des spec publish --manifest apps/incident-triage/pipelines/incident-list.toml
rac app publish apps/incident-triage/app.toml
rac app install incident-triage --version 0.1.2 \
--installation-id incident-triage-example \
--grant incident-read,incident-write,incident-pipelines
Publication requires authenticated managed-registry authority and exact pipeline
and descriptor references. A local build is an unsigned candidate; it does not
authorize installation. Follow the release lifecycle
for publication and grant review. Add the workspace's tenant identifier only for
tenant scope; omit it for personal scope. The installation opens through the
shared /apps/<installation-id>/run route. Agent documentation travels with the
release and is available through rac app docs <installation-id>.
Bounds and authoring lessons
The signed read returns at most 200 complete incidents, sorted by status, severity, title and id. Open records sort before resolved records. Each list page shows 25 records; this is local pagination over that snapshot, not server-side history pagination. Pending local operations merge into the same fixed group, whose shared runtime limit is 256 items. This release does not claim a complete incident history, arbitrary subscriptions or conflict-free text editing.
The previous example sorted on updated_at_ms, which the native record does not
define, and rendered a seeded incident without durable hydration. This version
uses only declared fields and empty initial state. Its incomplete next-action
prototype is excluded from the published graph. These repairs belong in the
app package; the existing host already provides the required primitives.
Desktop and mobile browser checks exercise the shared web host. They do not establish Android or iOS device conformance. Notifications, on-call rotations, timeline editing and infrastructure actions remain outside this app's scope.
Release and security lifecycle
How portable pipeline apps are hashed, signed, validated, installed, permissioned, upgraded, shared, forked, and revoked.
Build a vertical
How to build an application vertical on the platform, in order — Rust schema, ingestion, transforms, service surface, UI, then deployment.