Issues

An issue is one piece of work. Most of what you do in Orneos is create, change or read one.

Creating

Press c anywhere, or use New issue. A title is the only thing required; everything else can be filled in later or never.

Each issue gets a reference scoped to its team — ENG-42 — assigned by the server. Until the server has assigned it, the issue exists and is fully usable locally; the number is the one thing that waits.

Fields

Field	Notes
Title	Short statement of the work.
Type	Story, bug, feature, epic or task. Epics also show a child-progress chart.
Summary	Optional short summary, separate from the description; up to 255 characters.
Description	Rich text. Where the detail goes — and what Intent staleness watches.
Status	Which board column it is in. Columns are configured per team.
Priority	Urgent, High, Medium, Low, or none.
Assignee	One person. Press a on an open issue to take it yourself.
Project	Optional. See Projects.
Labels	Any number. See Labels.
Start date	When work is expected to begin. Drives the Timeline.
Due date	Deadline. Also drives the Timeline.
Parent	The issue this is a sub-issue of.
Relations	Typed links to other issues. See Sub-issues and relations.
Intent	The approved agreement about what this work should accomplish. See Intent.

Completion is recorded when the status moves to a done column, and cleared if the issue is reopened — so reopening clears the current completion timestamp rather than preserving a permanent completion-history record.

Editing behaviour

Ordinary issue-field edits update the interface optimistically and then write local state and queued work before background delivery. Visible text is not proof that those writes have completed or that the server accepted them. Intent has its own explicit editing and approval controls; see Intent.

Three consequences are worth internalising:

Seeing a change does not mean the server has it. The interface can reflect an optimistic change before local persistence completes. Server delivery follows queued persistence. This is the point of the architecture, and also its main caveat — see How sync works.

Supported local edits can continue while disconnected. Edits whose local queue writes complete can drain when you reconnect. See Offline and reconnect.

There is a brief moment between committing an edit and it being readable elsewhere. Blurring a field starts a short coordinated write. The interface handles this for you — anything that takes a snapshot of the issue, like copying a context bundle, waits for pending edits to settle first, so “edit, then copy” exports what you just typed rather than the previous text.

Concurrent edits

Two people editing the same issue at the same time is resolved per field, not per issue.

• Different fields merge cleanly. You change the assignee, they change the due date, both survive.
• The same field selects a winner using field timestamp ordering. This is not a guarantee that the last real-world edit wins: device-clock skew can affect the ordering. It cannot establish which edit best preserves the author’s intent.

If the server has moved on since your client last saw the issue, the background worker notices, re-applies your change against the newer version, and retries. You do not see this happen unless it fails repeatedly.

Undo

⌘Z undoes, ⌘⇧Z redoes. It covers mutations — creating, editing, deleting, moving — not text keystrokes inside a field, which your browser’s own undo handles.

The history is per tab and per session. It does not survive a reload, and it is not shared with your colleagues: undo reverses your action, it does not roll back the issue to a previous state.

Deleting

Deleting an issue removes it for everyone in the team. It is not a soft delete and there is no trash.

The original deleted issue is not restored by deletion Undo. In the deleting tab’s current session, Undo creates a new issue with a new reference, carrying the title, status, priority, type, summary, description, project and dates. It does not restore the original identity, assignee, parent, labels, discussion, Intent or relations. Treat it as partial recreation, not recovery of the complete issue.

Reconnect and replay are designed to respect deletion rather than resurrect the original record. Keep an independent copy before deleting work you may need to recover.

Related

• Board, Backlog, Timeline — the three ways to look at issues.
• Filters and saved views — narrowing and sharing a list.
• Comments and mentions — discussion on an issue.
• Intent — recording what the work is supposed to accomplish.