Writing things down
Tickets and operational tracking
Track bugs, delivery, incidents, releases, experiments, goals, sprints, reviews, risks, backlogs, discussions, and handoffs beside the context behind them.
“file a bug for the timeout we just hit”
A ticket, with the context of what you were doing attached.
“what bugs are open?”
Your workspace's open bugs.
“open a sev2 for the checkout failures”
An incident with a severity and a status timeline.
“track the 1.4.0 release”
A release record you can attach notes and a git ref to.
Choose the shape that matches the work
ContextStream supports twelve structured record shapes. They sit beside documents, plans, and memory because active work needs more than prose: status, ownership, dates, severity, metrics, relationships, or a completion state.
Tickets and backlogs
Tickets cover bugs, features, tasks, chores, epics, and an incident-shaped ticket when a normal issue lifecycle is enough. A ticket can carry priority, status, assignees, parent or sprint links, labels, story points, a due date, an external reference, and attachments to the records that explain it.
Use a backlog view to save a named filter and ordering over tickets—“now, next, later,” launch blockers, sprint candidates, or your personal queue. The tickets remain the source of truth; the backlog is a reusable view.
Use plans and tasks instead when the work is one goal broken into ordered, executable steps. Use a lightweight todo when it does not need assignment or a lifecycle.
Incidents and releases
An incident is the system-of-record for an operational event. It carries a severity from sev1 through sev4, affected services, an incident commander, reporter, timeline, and links to a ticket and postmortem. Its lifecycle covers detection, investigation, mitigation, resolution, a postmortem-pending state, and closure; milestone timestamps are retained with the record.
A release tracks a version through planning, rollout, release, rollback, or cancellation. It can identify environments, a Git reference, schedule and deployment timing, and the release-notes document. The release record answers “where is version 1.4.0 deployed?”; the linked release notes explain what changed.
Experiments, goals, and key results
An experiment records a hypothesis, control, treatment, primary and secondary measures, status, dates, and an optional result document. It can move from draft to running, pause, complete, ship, or be discarded without losing why the test was run.
A goal is the qualitative objective for a period. Goals can have an owner, start and end dates, a parent goal, and a health or completion status.
A key result is the measurable child of a goal. It has a unit—number, percent, currency, or boolean—and start, current, and target values. That separation lets “how are we tracking against the Q3 reliability goal?” return measured progress rather than a paragraph of optimism.
Sprints and reviews
A sprint is a time-boxed iteration with a name, goal, start, end, and planned, active, completed, or cancelled state. Tickets can point at the sprint they belong to.
A review can cover a pull request, code, design, security, architecture, product work, or another formal subject. It tracks the requester, reviewers, subject, decisions, and whether the review is requested, in progress, asking for changes, approved, rejected, or cancelled.
Repository-native pull-request reviews can remain in GitHub, GitLab, or Bitbucket. Create a ContextStream review when the review itself should become durable project context or spans artifacts outside one pull request.
Risks and discussions
A risk is an active register entry with likelihood, impact, category, owner, mitigation, contingency, and optional links to a ticket or incident. It is for something that must be managed over time, not merely the sentence “this might be risky” in a session.
A discussion is a deliberate workspace conversation with participants and replies. It is not a captured assistant transcript. Use it when the conversation itself is a shared project record with its own lifecycle.
Handoffs
A handoff records responsibility moving to another person or agent: sender, recipient, scope, summary, open questions, next steps, artifacts, and status. Pair it with a capsule when the recipient needs a portable bundle of the working context.
Handoffs are important enough to have their own guide: Handoffs.
What each shape looks like in real work
| Record | A useful example |
|---|---|
| Ticket | “Refresh can loop after laptop wake,” with reproduction, affected files, priority, owner, and the screenshot that shows the provider error |
| Backlog view | “Auth reliability: now, next, later,” a saved view over existing tickets rather than a second copied backlog |
| Incident | A sev2 login failure with affected services, commander, detection and mitigation times, timeline, and a postmortem still pending |
| Release | Version 1.4.0 moving from planned to production, linked to its Git reference, environments, deployment time, and release notes |
| Experiment | Test whether a shorter onboarding flow improves activation, with a named control, treatment, primary measure, and result document |
| Goal | “Make authentication failures recoverable in Q3,” with an owner and health |
| Key result | “Reduce unrecovered refresh failures from 1.8% to 0.3%,” with a percent unit and current value |
| Sprint | A two-week reliability iteration whose tickets point back to one goal and date range |
| Review | A security review of token rotation across code, runbook, and deployment configuration—not just one pull request |
| Risk | “Legacy clients may not accept the new signing key,” with likelihood, impact, mitigation, contingency, and owner |
| Discussion | A shared proposal thread where named participants must resolve the rollout window and preserve the replies as a project record |
| Handoff | The on-call transfer for the unresolved refresh failure, with current state, open questions, next actions, and evidence |
The point is not to create all twelve. Choose the smallest record whose fields answer the questions you will ask later. A simple defect stays a ticket. It becomes an incident when severity, affected services, timeline, and mitigation state matter.
Follow one operational chain
A login outage might begin as an incident, produce a bug ticket, create a risk for legacy clients, and block a release. The incident timeline records what happened. The ticket owns the code fix. The risk tracks exposure until enough clients have upgraded. The release records where the fix shipped. The postmortem and lesson preserve what should change next time.
Link those records instead of pasting the outage summary into each one. Then “is the incident resolved?” can have a different answer from “has the fix reached production?” and “is the legacy-client risk closed?”
Why track here rather than in Jira
You often should not move. If Jira or Linear is already the system of record, keep using it and connect the integration. The issues remain searchable beside code, decisions, and sessions.
Native ContextStream records are strongest for work born inside an assistant session or work that needs direct links to project knowledge. “File a bug for this” can preserve the title, scope, attempts, related files, plan, runbook, diagram, or session context while it is still fresh.
Link the chain
The most useful records are connected:
- a ticket can belong to a sprint or epic and attach a plan, task, document, diagram, runbook, handoff, todo, or capsule;
- an incident can link its ticket and postmortem;
- a release can link its release notes and Git reference;
- an experiment can link its result write-up;
- a risk can link the incident or ticket that would realize it;
- a handoff can link everything the recipient needs.
Link the source record instead of copying the same explanation into several places. One updated runbook is safer than four pasted versions.
Personal and shared tracking
The same record types work for an individual or a team. A personal risk list, release checklist, or backlog can stay private. Shared records appear only to authorized workspace members, and team views do not override the permissions of connected services.
If it doesn't work
A record doesn't appear in the dashboard. Check the workspace, project, personal/shared mode, filters, and status. A personal record will not appear in a team-only view.
I want this in Jira instead. Connect Jira and use it. The integration makes those issues searchable here without moving them.
Too many shapes. Start with tickets. Move to the dedicated incident, release, experiment, goal, review, risk, or handoff record when its additional fields and lifecycle become useful.
A discussion is not a transcript. A discussion is a structured
workspace conversation. A transcript is captured client/session history. Use
the one whose lifecycle you actually need.