Vector

The public landing shows the configured owner's name, one configured statement of purpose, and a sign-in link. It contains no pricing, feature tour, customer testimonials, or invented metrics. The configured “Powered by <product> · runeditrun.com” credit is shown only when enabled.

Every operator can see and act on every team, issue, intake item, cycle, project, label, and shared saved view, and on every notification addressed to them. There are no roles. Team membership organises work and never grants or restricts access. A private saved view (VIEW-002) is the only record one operator cannot see.

Operators are invited and removed in settings. The operator configured at setup can be removed only by themselves. Policy: operator.management.v1; default: any operator may invite or remove.

Settings hold one IANA workspace timezone. Every calendar day, due reminder, cycle start and end instant, and seven-day window named in this contract is evaluated in that timezone. Changing it never rewrites stored instants, closed cycle snapshots, or reminders already delivered.

Vector rejects removal of the last operator. A successful removal revokes that operator's sessions, unassigns their non-terminal issues, transfers each project they lead and each shared saved view they own to the operator performing the removal — or to the longest-standing remaining operator when they removed themselves — deletes their private saved views and their notifications, anonymises their references in retained comments, activity, and audit records, and writes one activity entry per changed issue and project.

A team has a name and an identifier prefix, each unique across archived and non-archived teams. The prefix is two to ten uppercase letters and cannot be changed once the team has an issue, so existing identifiers stay resolvable. Every issue belongs to exactly one team.

Every team has an ordered list of workflow statuses with at least one status in each of the Intake, Backlog, Unstarted, Started, Completed, Canceled, and Duplicate categories, and status names unique within the team. Operators can add, rename, and reorder statuses; a status never changes category, and no category is added or removed. A team's default status in a category is the first status of that category in workflow order, and every clause naming a category as a destination moves the issue there.

Archiving a team stops new issues, intake, and issue moves from targeting it while preserving its issues, cycles, projects, identifiers, and history; a signal source request naming an archived team creates nothing and returns 409. Unarchiving restores normal use. Teams are never deleted; archiving is the only terminal state.

Removing a workflow status requires a destination status in the same category and atomically moves every issue to it. Vector rejects removal of a category's last status and records the status mapping in audit history.

An operator can create an issue with a required title and team plus an optional Markdown description, assignee, project, cycle, priority, labels, estimate, due date, expected outcome, customer impact, and custom fields. It starts in the team's default Backlog status unless another non-Intake status is explicitly chosen. Policy: issue.defaults.v1; default: unassigned, no priority, no cycle, and no project.

An issue identifier is its team's prefix, a hyphen, and an integer one higher than the highest ever allocated under that prefix, so a number is never reused after an issue is deleted. The identifier never changes, including when the issue moves teams (ISSUE-012); a prefix therefore records where an issue started, not where it lives.

An issue has exactly one priority: Urgent, High, Medium, Low, or No priority. No priority is the default and sorts after Low.

A version-checked operator mutation (ISSUE-006) can move an issue in any direction among the Backlog, Unstarted, Started, Completed, and Canceled statuses of its team's workflow. Vector rejects moving any issue into an Intake status. Leaving Intake uses INTAKE-005, INTAKE-007, or REL-003; entering or leaving Duplicate uses REL-003 or REL-005. Entering Completed records the completion time and entering Canceled records the cancellation time; leaving one of those categories clears the time it recorded and removes no activity.

An issue has at most one assignee. Assigning, reassigning, or unassigning it takes effect immediately and records the actor, the previous assignee, and the new assignee.

Every issue carries an integer version that increases by one on each mutation that appends an activity entry under ISSUE-007. An issue mutation carries the version the client last read; if the stored version is higher, Vector rejects the mutation with 409 and returns the current issue and version, changing nothing. Adding a comment, evidence revision, follower, or notification does not change the version and is never rejected as stale.

Creation and every change to title, description, team, status, priority, assignee, project, cycle, estimate, due date, labels, expected outcome, customer impact, custom fields, duplicate target, parent, or dependency append an immutable activity entry recording the time, the previous value, the new value, and the actor — the operator, or the named automation when a cycle closure, deferral return, or import acted.

Any operator can add a Markdown comment, and can edit or delete any comment; the entry records who acted. An edited comment shows its edit time. Deleting a comment removes its body, attachments, links, and search entry, leaves a tombstone and an activity entry in the thread, and does not remove the follower state it created.

Operators can attach files and named HTTPS links to an issue or a comment. Removing either records the action; removing a file also deletes its blob under BASE-DATA-003.

Deleting an issue removes its comments, attachments, links, evidence revisions, dependencies, parent link, follower state, notifications, activity, and search entry; its children become root issues, and a duplicate is removed from its canonical issue's list. Vector rejects deleting a canonical issue that still has duplicates. Closed cycle snapshots (CYCLE-005) and audit entries keep only its identifier, and its source idempotency records (INTAKE-002) are retained so a re-delivery cannot resurrect it. Policy: issue.can-delete.v1; default: any operator.

An issue estimate is absent or an integer from 1 through 100 points. Changing an estimate never rewrites a closed cycle snapshot.

Moving an issue requires a non-archived target team and an explicit target status in the same category as its current status, including Intake so a misrouted intake item reaches the right team without a decision. The move preserves the identifier (ISSUE-002), uncommits the issue from any cycle (CYCLE-002), keeps its project, assignee, labels, and history, and writes one activity entry. All of it happens or none of it does.

Typing @ in an issue description or comment offers matching operators, and choosing one records a mention of that operator. Text resolving to no operator is stored and shown literally and mentions nobody. A mention adds a follower (NOTIFY-002) and notifies once (NOTIFY-001); editing text to add a mention notifies only the newly mentioned operator, and removing a mention notifies nobody and withdraws no delivered notification.

A label belongs to the workspace and has a name unique among labels and a colour. Any operator can create, rename, recolour, and delete one; deleting a label removes it from every issue and from the filters of saved views naming it, and deletes no issue. An issue carries up to the number of labels in seed.json → limits.

An unsubmitted new-issue form is retained in the operator's browser and restored the next time they open new issue there. A draft is not a record: it appears in no list, search result, notification, or export, and becomes an issue only when that operator creates it.

An operator can record that one issue blocks another, across teams, and can remove the link. Vector rejects self-links, a link that already exists in either direction, and any link that would create a directed cycle.

An issue is shown as blocked while any issue that blocks it is outside a Completed, Canceled, or Duplicate category. Blocking never changes the issue's workflow status by itself.

Marking an issue as a duplicate requires one canonical issue that is neither itself nor already a duplicate, moves it to the team's default Duplicate status, and preserves its description, comments, evidence, attachments, and activity under the duplicate issue.

A canonical issue lists every direct duplicate. If it is later marked duplicate, Vector atomically repoints its duplicates to the new canonical issue, so a duplicate chain or cycle is never exposed.

Undoing a duplicate decision removes the canonical link and restores the issue's most recent non-terminal status, or its team's default Backlog status if it has none, while preserving both decision activity entries.

An issue has at most one parent. Vector rejects self-parenting and ancestry cycles; changing a parent never changes status, team, project, cycle, or assignee, and deleting a parent makes each direct child a root issue.

A registered signal source (INTAKE-011) creates an intake issue with a title, team, observed time, its source ID, source display name, source record identifier, source revision identifier, summary, link, and optional structured measurements and customer reports. An operator creates one with a title and team and any of the same descriptive fields, attributed to that operator instead of a source. Either way it starts in the team's default Intake status and appears in Needs decision (CURR-002) within 5 seconds.

Re-delivery of the same source ID, source record identifier, source revision identifier, and normalised payload returns the original result and creates nothing. Re-delivery of an identity whose issue has since been deleted (ISSUE-010) returns 410 and creates nothing. Reusing an identity with a different payload returns 409 and changes nothing.

A new source revision identifier for an existing source record appends immutable dated evidence even when revisions arrive out of order. The issue orders evidence by observed time, then receipt time, and shows a field-level change from the preceding observed revision.

An intake issue shows the evidence behind its attention reason, impact measurements, likely cause, recommended assignee, and suggested priority. Each assertion names whether it came from a source, an operator, or a policy; Vector does not invent or silently infer assertions in core.

Accepting an intake issue atomically records the actor, the time, and an optional reason; applies the chosen assignee, priority, cycle, and Started or Unstarted status; and clears any deferral. It leaves Needs decision and reaches its new Current and My work sections within the CURR-008 window.

Deferring an intake issue records the operator, an absolute return time strictly in the future, and an optional reason, and removes it from Needs decision. It returns there exactly once — within 5 minutes of the return time, or within 5 seconds of a new evidence revision (INTAKE-003), whichever comes first — and the return atomically clears the deferral and leaves the earlier decision visible. An operator can defer it again or end a deferral early.

Declining an intake issue requires a reason, moves it to the team's default Canceled status, and removes it from Needs decision without deleting its evidence or decision history.

Evidence received after an issue is Canceled or Duplicate is appended and visible but never reopens, reassigns, reprioritises, or resurfaces the issue.

A signal source request from an unknown or revoked source, or carrying a wrong signature, returns 401; one whose body fails validation returns 400; one naming an archived team returns 409 (TEAM-003). None of them creates anything. A valid request that cannot be stored durably returns 503 so the source retries. No request is acknowledged before its idempotency record and evidence are durable.

Suggested assignee, priority, and start state are selected by the intake recommendation policy and are always editable before acceptance. Policy: intake.recommendation.v1; default: use an explicitly supplied team and assignee, otherwise leave the issue unassigned with No priority and Unstarted status.

An operator registers a signal source with a display name, a source ID unique in the workspace, and a signing secret; the signal.source.v1 adapter normalises that source's signed request into INTAKE-001. Rotating a secret accepts both secrets for a configurable overlap of at most 24 hours and then rejects the previous one. Revoking a source rejects every later request under INTAKE-009 and deletes no evidence. A secret is shown once at registration or rotation and never again.

Current places an issue in at most one section using this precedence: Needs decision, Now, Next, then Recently done. Canceled, Duplicate, deleted, and actively deferred issues do not appear.

Needs decision contains every Intake-category issue whose deferral has expired or is absent and which has not been accepted, declined, or marked duplicate.

Now contains non-terminal issues outside the Intake category that are overdue or in a Started status, excluding anything already in Needs decision. An issue is overdue when its due date is earlier than the current calendar day in the workspace timezone (OPS-003).

Next contains non-terminal issues in an Unstarted status that are committed to their team's active or next cycle (CYCLE-001) or due within the next seven calendar days, excluding anything already in a higher-precedence section.

Recently done contains issues moved to a Completed category in the previous seven calendar days, newest completion first.

Every issue in Current shows one primary inclusion reason — Awaiting decision, Started work, Overdue, Cycle commitment, Due within seven days, or Completed within seven days — and every applicable context reason from Customer escalation, Unresolved dependency, Unassigned urgent work, Project risk, and New evidence since the most recent intake decision.

Within a section the default order sorts by priority (Urgent first, No priority last), then by due date (overdue first, then earliest first, then issues with no due date), then by most recent update, and finally by stable identifier, so the order is total and stable. Policy: current.ranking.v1.

A decision or issue mutation that changes an issue's Current membership, section, or reasons is reflected in an already open Current view within 5 seconds without an operator-initiated reload, and in the next response to any other request.

Operators can filter Current by team, project, priority, item type, assignee, and attention reason. The default includes all teams and all operators and shows Recently done.

My work contains every non-terminal issue assigned to the signed-in operator outside the Intake category, grouped disjointly in this precedence: Waiting for issues blocked under REL-002, Now for those the CURR-003 rule would place in Now, and Next for every issue still remaining, each group ordered by CURR-007. An issue assigned to the operator while in an Intake status appears in Current's Needs decision, not here.

Completed, Canceled, Duplicate, and actively deferred issues never appear in My work; an operator reads their finished work from Current's Recently done filtered to themselves (CURR-005, CURR-009). When no issue qualifies, the view states the operator is caught up and offers new issue and Current as next actions.

My work shows one row for each team that has an active cycle containing an issue assigned to the operator, giving that cycle's name, start and end dates, and progress, with completed and total committed scope labelled in the unit CYCLE-003 used.

A project has a name unique in the workspace, a Markdown description, exactly one lead who is an operator, an optional target date, a lifecycle, an optional colour, an optional icon, and custom fields. Its lifecycle is Planned, Active, Completed, or Canceled, and it starts as Planned.

Only an operator changes a project's lifecycle. Completing or canceling all of its issues never completes or cancels the project.

An issue belongs to at most one project. Removing an issue from a project or archiving a project never deletes the issue; deleting a project detaches all of its issues but deletes none of them.

Project progress counts issues: completed project issues divided by all project issues outside the Canceled and Duplicate categories. The interface shows the completed and total counts beside the percentage and reports no progress when the denominator is zero.

Health is reported only for projects in the Active lifecycle; every other lifecycle reports no health and is excluded from health filters and counts. A remaining issue is a project issue outside the Completed, Canceled, and Duplicate categories. An Active project is Blocked, At risk, On track, or Unknown, evaluated in that order. The default reports Blocked when at least one remaining issue exists and either an Urgent remaining issue has an unresolved blocker (REL-002) or every remaining issue is blocked; At risk when its target date is in the past, a remaining Urgent issue is unassigned, or its remaining estimated points committed to any team's active cycle exceed that cycle's capacity; On track when a target date in the future, every applicable capacity, and every remaining active-cycle estimate exist and no earlier rule matches; and Unknown otherwise. Remaining scope exactly equal to capacity is not At risk. Policy: project.health.v1.

Every Blocked or At risk project shows the exact issues and measurements that triggered its health, including unresolved dependencies, unowned urgent work, target-date exposure, and committed scope against capacity.

The Projects view shows the count of projects in each health and lifecycle state and can filter by lifecycle, health, lead, team, target date, and label. Counts and rows use the same active filters.

Later issue edits update live project progress and health but never rewrite a closed cycle snapshot shown in that project's history.

Archiving a project removes it from the default portfolio and stops new issues from joining it while preserving its lifecycle, issues, history, and closed-cycle snapshots. Operators can include archived projects in filters or unarchive one.

A cycle belongs to one team and has a name unique within that team, a start instant, an end instant after the start, and an optional capacity in estimate points, all interpreted in the workspace timezone (OPS-003). Vector rejects a cycle whose dates overlap another cycle of the same team, so a team's active cycle — the one whose start is at or before now and whose end is after now — is unique, and its next cycle is the cycle of that team with the earliest start at or after the active cycle's end.

A non-terminal issue can be committed to at most one cycle, and only to a cycle of its own team. Committing, moving, and uncommitting record both cycle identifiers and update both cycles atomically.

Cycle progress is completed committed estimate points divided by all non-Canceled, non-Duplicate committed estimate points when every included issue is estimated; otherwise it uses issue counts and labels the result by issue count. With no included issues it shows No committed work and no percentage. Capacity risk is Unknown unless capacity and every remaining estimate exist, At risk when remaining points exceed capacity, and Within capacity otherwise.

Within 5 minutes of a cycle's end instant Vector closes it exactly once however many times the closing job runs, and by default moves committed issues in an Unstarted or Started status to the team's next cycle (CYCLE-001) and uncommits committed issues in an Intake, Backlog, Completed, Canceled, or Duplicate status. A closed cycle's name, dates, capacity, and snapshot cannot be changed, and a closed cycle is never reopened. Policy: cycle.rollover.v1.

Closing a cycle records committed and completed issue IDs, each issue's project ID at close, estimate totals, capacity, progress, additions and removals during the cycle, and the close time. The snapshot is immutable.

If rollover is required and no next cycle exists, the cycle still closes, its unfinished issues become uncommitted, and one visible failed-operation entry names the affected issues; creating a later cycle does not move them.

Search covers issue identifiers, titles, descriptions, expected outcomes, customer impact, comments, evidence summaries, project names, and label names, and returns within 500ms. Issues of archived teams and projects are excluded unless the operator asks for them.

An exact issue identifier lookup reads the primary record and returns it even while full-text indexing is delayed or failed.

Created or changed searchable text appears in full-text results within 10 seconds. A failed indexing job is visible to operators with its last successful index time; Vector never presents known-stale results as complete.

Issue lists can filter by status, status category, priority, assignee, team, project, cycle, label, due date, and blocked state; sort by newest, oldest, Urgent-to-No-priority, workflow status order, due date, or last update; and group by none, status, assignee, priority, project, cycle, or team. Completed issues are hidden by default outside Current.

An operator can save a named combination of filters, sort, and grouping as private or shared, then update, duplicate, or delete it. A private view is visible and editable only by its owner; any operator can open or duplicate a shared view, but only its owner can update or delete it, and ownership changes only under OPS-004. Deleting a view never changes an issue.

The filters, sort, and grouping an operator last applied to Current, My work, the Projects portfolio, and each issue list are stored for that operator and restored on their next visit from any browser, and one visible control resets them to the defaults. Opening a saved view never changes the stored controls of the list it was opened from.

An operator can select several issues in a list and set status, assignee, priority, project, cycle, or labels on all of them in one operation, up to the batch limit in seed.json → limits. The operation is atomic: if any selected issue fails ISSUE-004, ISSUE-006, or CYCLE-002, nothing is written and the response names the failing issues by identifier. A successful operation writes one activity entry per issue.

The command palette searches issues, projects, saved views, and available commands from one input. The up and down arrows move the highlight, Enter opens the highlighted record or performs the highlighted command, and Escape closes the palette without acting.

Outside editable controls, Command/Ctrl-K opens the palette, C opens new issue, G then M opens My work, G then C opens Current, G then P opens Projects, and Escape closes the topmost transient surface. Every command also has a visible, keyboard-operable control.

The up and down arrows move a visible focus indicator through the rows of the active list, Enter opens the focused row, X adds or removes it from the selection VIEW-004 acts on, and Escape returns focus from an open detail pane to the row it was opened from. Changing a filter, sort, or grouping keeps the focused row focused while it remains in the list and focuses the first row when it does not.

Vector creates an in-app notification, visible within 5 seconds, for assignment of an issue to the operator, a direct mention (ISSUE-013), a comment on an issue they follow, the return of an intake item they deferred, the resolution of the last blocker on an issue assigned to them, and a due reminder (NOTIFY-005). Vector delivers notifications on no other channel; the only mail it sends is the sign-in link BASE-ACCESS-001 requires.

Issue creators, assignees, commenters, and directly mentioned operators follow the issue automatically; an operator can follow or unfollow it explicitly without changing anyone else's following.

An action never notifies its actor. One event creates at most one notification per recipient and issue even when the recipient qualifies through several follower rules.

Opening a notification marks it read, an operator can mark all of theirs read in one action, and the interface shows their unread count. An operator can mute an issue or an event type, which suppresses only their own later matching notifications and alters neither activity history nor another operator's notifications.

Within 5 minutes of the configured daily reminder time — 09:00 in the workspace timezone by default — Vector notifies the assignee once for each incomplete issue assigned to them that is due that day, and once more on the first run after it becomes overdue. Changing a due date makes the new date eligible and never repeats a reminder already delivered for the same issue and date.

The portable export contains a manifest, original attachment bytes, and every operator, team, workflow status, issue, comment, attachment metadata, link, relation, evidence revision, intake decision, project, cycle and snapshot, label, saved view, notification, custom field, non-secret setting, idempotency record, failed operation, and audit entry. It never contains a session, signing, source, or provider secret.

Separately from portable restore, an operator can preflight an import of issues supplied as CSV rows or as a JSON array of objects with the same field names, before anything is written. The fields are title, description, team, status, priority, assignee, project, cycle, labels, estimate, due date, expected outcome, customer impact, source ID, and source record ID. The preflight validates the mapping, the timestamps, and every team, status, assignee, project, cycle, label, duplicate, and dependency reference, and reports every row that would fail with its row number and reason.

Applying a successful preflight writes the batch atomically, preserves supplied creation and update times, and records an import-run identifier. A failed apply writes none of the batch.

Reapplying the same import-run identifier and source record identifiers creates no duplicates and returns the first run's result. A mapped import creates normal activity and one audit entry for the run, and no operator notifications.

pnpm import restores a portable DATA-001 archive without synthesising activity, audit entries, notifications, or new timestamps; its records are equivalent after export, import, and export as BASE-DATA-001 requires.