Work

Reading the detail screen

Open a work item to read its fields, where it belongs, its workflow and related records. The list beside it opens another item; filtering the list does not change the item already open. On a narrow screen the list moves above the details.

A soft edge on scrollable content indicates that more lies beyond that edge. It clears as you reach the boundary; keyboard focus stays readable. Scroll inside a list, table or panel to reach its remaining content. The edge is a reading aid and does not change your permissions or save your edits.

Saving work fields

Editing work requires Work edit permission in the active solution. Save validates the fields and placement before writing them. The field change and its history entry are stored together; if either fails, neither is saved. If the item changes while a save is being processed, the form keeps your submitted values and asks you to review the latest version. Check the message before trying again. Other work types retain this legacy form behavior. A saved Story uses the protected workspace described below and compares the revision loaded when it was opened.

The Story workspace

A saved Story shows its code and title once at the top, followed by the existing view switch and actions. The Stories working set sits beside the details, or behind Show records when the available width is narrow. Find a record and Status filter only this working set; they do not change the open Story. Its current marker, a notice when the current Story is outside the results, and Back to list keep that context visible. Filters and scroll are remembered for this person and solution in this browser session when storage is available; field drafts are not stored there.

Placement shows Initiative, Epic and Work package as separate roles. Editors may change the allowed selections together with the Story fields; a Story under a parent or package inherits its initiative. Open links read those related records through the same protected navigation. A selected target that is no longer available stays visible as unavailable rather than silently clearing it. Story details retains title, code, read-only status, priority, owner, dates, external reference and description, plus the existing health summary. Status changes remain separate in Status at the top. Workflow, next gate, Activity, handover, Implementation and related records follow in their existing order. History opens in the shared right panel.

Save changes saves fields and placement together, without navigating away. Unsaved changes, Saving and Changes saved report the result. The server rechecks permission and compares the opening revision. If another person or agent has changed the Story, the save is refused and your draft stays visible. Review saved values shows the current saved fields; Use saved version and discard draft explicitly replaces your draft with that version. You may then edit and save again. A field-validation refusal keeps the fields for correction. If a save response is lost or editing permission is refused, the draft stays visible and another save is blocked until you reload. Reload saved Story and discard draft loads the saved record and abandons this draft; the browser may also ask before reloading.

Story tasks described below have independent save boundaries. Other page commands that submit a separate form ask about dirty Story fields and registered task drafts first. Saving fields does not save a relation, a status change, sharing, a code link or a proposal as part of the same transaction. A viewer may read the Story and use its working set and History but cannot edit its fields. Browsers without protected history navigation show the fields read only.

Leaving an editable workspace

On a saved Story, leaving edited fields, placement or registered task drafts asks one question naming the affected drafts. Keep editing stays on the current item. Save and continue proceeds only after every affected save succeeds. Independent saves can partly succeed: saved fields remain saved while a failed task stays open with its own draft and error. A refusal or conflict keeps the remaining draft open. Discard and continue abandons those local changes and opens the requested destination. If an independent task has updated the saved Story, discarding older field edits keeps that completed task. Reviewing and adopting saved field values does not erase independent relation or task drafts. A save response for another request, target or revision is unconfirmed: your draft stays visible, field editing and another submission are blocked, and Save and continue cannot replay it. Reload the saved Story and review what actually reached storage before deciding on a new edit. While a save is still pending, leaving stays blocked. Screen links, Go to, search destinations, browser Back and Forward, scope changes and sign-out use this decision. A section anchor stays within the current item. A quick look opens its preview beside the item and keeps the current draft without asking to leave. Reloading or closing the page uses the browser's own limited warning.

Workspace editing works in two ways. Where the browser can ask before any same-page change (protected navigation), every exit, including Back and Forward, asks first. Where it cannot, for example Safari on iPhone, editing uses kept changes in this tab (see below). Where the browser can do neither, editing is read-only and normal navigation remains available. Saved Story detail screens use this workspace. Creating a Story uses its own panel (see Creating a story); editing other work types retains its existing form. Story relation, code, design proposal and sharing tasks join the same leave decision with their own save actions and permissions. Under protected navigation, task drafts stay in memory for their target lifetime and are not recovered after a reload.

Kept changes in this tab. Some browsers, such as Safari on iPhone, cannot ask before their own Back or Forward gesture changes the page. There the Story says so under its heading and keeps every unsaved field and eligible task change in this browser tab as you type, for this person, tenant, solution and record only. Links, peers, panels, solution switches and Sign out still ask Keep editing, Save and continue or Discard and continue first. After a native Back or Forward, return to the Story in the same tab: the kept changes come back with Restored unsaved changes kept in this tab and remain unsaved. Nothing is stored or sent until you choose Save. Saving checks the changes against the version you first opened; if someone saved a newer version meanwhile, you review both before deciding, exactly as for any conflict. Discard kept changes removes them.

Kept changes expire eight hours after your last change and are removed the next time the page looks. Signing out removes every change kept in the tab. They are not shared with other tabs or devices, and the browser may remove them earlier, for example in private browsing or when its storage is full. If the tab cannot keep a change, that change is not accepted, earlier kept changes stay, and editing pauses with an explanation. Passwords, sign-in values and one-time results are never kept: Share outside the team, which shows a package token once, needs a browser with protected navigation. If a save was sent but its result never arrived, for example because you went Back while it was saving, it may already be stored. Nothing is sent again: on return the page shows your kept changes beside the saved values. Choose Keep my changes for an explicit save to save them yourself (a conflict appears if the earlier save went through), or Discard kept changes. If your roles no longer allow editing, kept changes are not shown and can only be discarded.

Creating a story

New story at the top of the Stories screen, on its Overview, Board and Table and on a saved Story, opens the New story panel beside the page; it does not leave the page you are on. It needs Work edit permission in the active solution. The panel holds Title (required), Description, Placement (Initiative, Epic and Work package), Details (Priority, Owner, Code, Start date, Due date, External key and External link) and Related items. A new story starts in Backlog; change its status on the Story afterwards. A story under an epic or in a work package takes its initiative from there, so Initiative is then not chosen here. Leave Code empty for an automatic one.

Related items offers the valid relations of layers 1 and 2 with their direction and target. Add to draft lists the choice under the fields; Remove takes it off. They are linked when the story is created. Decisions, standards, references, risks and questions are linked from their own records.

Create story checks the fields and placement and creates the story in the solution where you started the draft; the panel then closes and the new Story opens. A field problem keeps your input with the message. If the active solution changed after you started, nothing is created: switch back or discard the draft. If the answer is lost or does not match the request, the story may already exist: the form stays as it was, nothing is sent again, and Close and check the list opens the Stories table so you can look before creating it again.

The draft lives in the panel while you move between pages and comes back when you open the panel again; it is not stored on this device and a reload or a closed tab loses it. Closing the panel or Cancel with unsaved input asks first: Keep editing stays, discarding closes it. On a phone the panel opens as a sheet from the bottom. + Story on an epic or a work package, and older links to the create page, open the Stories list with this panel, the epic or work package already chosen.

Story panels and independent tasks

History, Link code, Propose change and Share outside the team open in the existing shared panel area. The panel heading and Task target identify the Story it will read or change. A clean panel follows the Story subject. Pin task keeps that target while you read a neighbour; an edited or pending task also holds its own target. Follow current Story returns to the current Story through the same leave decision. Back shows the earlier panel. Closing, changing panel layout or opening beyond panel capacity asks about any affected task drafts, including hidden panels. A pending task blocks those exits until its response arrives.

Link code accepts a code URL, detected or selected kind and optional title. Propose a design change accepts add, change or retire, an existing design record when needed, kind, subtype, title, description, acceptance and note. The proposal applies when the Story is Done. These actions require Work edit permission; proposing also requires an open Story. Each task saves independently of Story fields and reports Unsaved task, Saving task or Task saved. Validation keeps your inputs. A lost or mismatched response, a missing target or refused permission keeps the draft and blocks another attempt until reload, because the first operation may already have completed.

Add related item lists allowed relation-and-target choices, with direction, relation name and record code; its optional note is saved on the link. Its explanation, named task target, fields and save action sit inside the section body with the shared spacing. The explanation stays below the heading so the heading has room on narrow screens. Related cards show their saved relation note below the record details, together with their evidence and direction. An incoming work relation can also preview its source. History filters stay inside the panel; on narrow screens, focus the History changes region and scroll horizontally to read all three columns. Open History with Enter and close it with Escape to return focus to its opener. If an editable panel has unsaved changes, Escape opens the same Keep editing or Discard and continue decision as its close action. Preview opens a quick look of a selected requirement or work item without replacing the Story subject. Unlink relation removes only that scoped link, never its target record. Adding a child continues through the normal creation screen and guarded navigation; the workspace does not automatically retry child creation. Relation changes require Work edit permission.

Share outside the team requires Integrations permission. Choose recipient, masked brief or package token, expiry, extra masked terms and note. No message is sent. If task details cannot be refreshed after saving, the draft and receipt stay in place; Refresh task details retries only that read. A successful share shows its code and a brief download; a package token is shown once. Copy and review it before choosing Done with this receipt. Until then, leaving treats the receipt as unfinished work; Save and continue cannot create another share to recover that token. Discard explicitly abandons the receipt. Existing shares show recipient, mode and expiry; End share revokes that share. If the response is lost, reload and review existing shares before deciding on a new share.

Sharing a package outside the team

On an epic, story or task, Share outside the team (Integrations permission) hands the package — the item and everything below it — to a subcontractor or an outside team until an end date. A masked brief is a Markdown document: what to do, the requirements and acceptance criteria with their tests, how the work is checked, constraints, standards and the agent policy. The client's name, the solution's name, the people of the workspace, e-mail addresses, phone numbers, secrets and the words you add are replaced. Check it before you send it.

A package token lets their coding agent connect: it sees only get_package_brief, get_agent_policy, update_work_status, link_code, report_test_result, report_acceptance_result and ask_question, and only for the package's items, criteria and tests; everything it reads is masked, it gets none of your notices, every REST endpoint refuses it, and it cannot move work to Done — a person here accepts the work on its evidence. End the share to stop the token at once.

Initiative and demand

• Every work item belongs to an initiative. Top-level work picks it on the New work form (or goes to the solution's default); work under a parent follows the parent's, and moving it under another parent moves it and everything below it. Defects without a parent go to the quarter's maintenance initiative.
• No work without a demand: under the tenant's demand gate, work is committed — to Ready, or straight to In progress — only when its initiative answers a demand.
• The initiative chosen in the context row below the top bar filters this list; choose All open there to see every open initiative. Solution → Tests → Known defects lists the solution's open defects whichever initiative fixes them.

The two axes

Story or task?

Both sit under an epic and both can have subtasks. Coding agents work on stories; if a task turns out to need code, create a story for that part.

Linking work to requirements

• Implements: the requirement the work brings to life (epic → business / stakeholder; story → stakeholder / functional / non-functional / technical; task → functional / non-functional / technical / solution).
• Covers: the acceptance criteria a story or task must satisfy. Criteria are not copied into work.
• Serves: the objective a theme or epic contributes to. Delivers: the project requirement a work package delivers.
• Constrained by, Depends on, Conflicts with, Relates to complete the picture.

Keep in mind Retired requirements cannot be implemented. Epics, stories and tasks without a requirement are flagged as scope creep, and work on Draft requirements is flagged too.

Design changes

An epic, story, task or defect can carry design changes: add, change or retire a design record (BDR, FDR, NFDR, TDR, ADR) on the work page. They are applied to the solution's design when the work is Done; if two items change the same record, the first Done wins and the other's change must be looked at again.

Agents on the work

• An item an AI agent is working on shows which agent and since when; other agents see it and are told not to work on it in parallel. If one writes to it anyway, Agent health raises a signal (DRF-21).
• When an agent stops with the item unfinished it leaves a handover note — done, open, next step, anything half-done — shown on the item and to the next agent that opens it.

Status and measures

Each type has its own flow: stories Backlog → Ready → In progress → Code review → Verification → Done; tasks Backlog → Awaiting approval → Ready → In progress → Check → Done; epics Idea → Analysis → Ready → In delivery → Done; subtasks To do → Doing → Done. Coding agents may move stories to In progress and Code review and tasks to In progress and Check; approval, verification, check and Done are people's decisions.

Themes, epics, packages, stories and tasks show two measures: delivery progress (stories and tasks done, or subtasks inside a single story or task) and acceptance (covered criteria verified as met). A large gap means work is reported done faster than it is proven.