Where a task came from

Every task remembers how it came into being: who filed it, and — if an agent filed it while working on something else — which task, session, and stage that was. CodeHerder calls this a task’s origin. Beyond the single moment of filing, a task also sits in a wider web of connections to other tasks, sessions, and members — CodeHerder calls that its lineage.

Origin: how a task was filed

A task’s origin is captured once, the moment it’s created, and never changes afterwards. CodeHerder records one of a few kinds:

• Filed by an agent — an agent’s session created this task while it was working on something else.
• Filed by a human — a person created it directly, not through a session.
• Filed through an inbound webhook — an external system created it through one of your inbound webhook endpoints. ch task show reports this kind as integration — that’s the word you’ll see in the origin: row, not a reference to your connected GitHub, GitLab, Slack, or PagerDuty integrations.
• Filed through the API — created some other programmatic way, without a session or a webhook.

Reading it on the task page

Open any task and look for its Origin row. It reads as a sentence, built from whatever CodeHerder knows:

Filed by <member> during <session> while working on <task> (<stage>)

Each part of that sentence — the member, the session, the originating task, its stage — appears only when CodeHerder recorded it. A task an agent filed mid-session typically shows the whole sentence; a task you filed directly usually just names you.

Some tasks show Origin unknown instead. That’s expected, not an error — it means CodeHerder has no origin recorded for that task, most commonly because it was created before CodeHerder started tracking origins at all.

From the CLI

ch task show <taskId>

always prints an origin: row — unknown when nothing was recorded, otherwise the origin kind followed by whichever of the member, session, originating task, and stage CodeHerder knows, for example:

origin:   agent_session, by Builder (<memberId>), in session <sessionId>, while working Fix the flaky upload test (<taskId>), at stage code

Lineage: what a task connects to

Beyond that one moment of filing, a task’s Lineage section shows the wider web of connections around it: who created it, what filed it and what it in turn filed, what it depends on and what depends on it, its parent and child tasks, the sessions that worked on it and the agents they ran as, and — for a scheduled task — the schedule that spawned it.

On the task page

Every task page has a Lineage section, subtitled “how this task connects to the members, sessions, and tasks around it.” It draws a small graph rooted at the task you’re looking at.

From the CLI

ch task lineage [<taskId>] [--depth N] [--direction up|down|both]

Without a task ID, it uses the task you’re currently working on. It prints an indented tree: each line names a connected member, session, task, or schedule, and how it relates to the one above it.

• --depth controls how many hops out from the task to walk. It defaults to 3 and can go up to 6.
• --direction controls which way to follow connections: up reaches this task’s parent task, whoever created or filed it, the tasks that depend on it, and the schedule that fired it, if any; down reaches its child tasks, what it depends on, the sessions that worked on it and the agents they ran as, and anything it filed while it was being worked; both (the default) follows every connection either way.

A large or heavily-connected task’s lineage can be bigger than CodeHerder is willing to walk in one request. When that happens, both the task page’s Lineage section and ch task lineage say so plainly, and distinguish two different reasons a node might be missing:

• The walk hit its limit before reaching everything — some connections genuinely weren’t shown.
• A connected member, session, or task is hidden from you — you don’t hold a role in the workspace it belongs to, or it no longer exists.

CodeHerder never blends these two counts into one vague “some items not shown” — it tells you how many of each, so you know whether to widen your search or simply accept you can’t see that part.

A task a schedule fires

A scheduled task shows the schedule that fired it as a connection in its lineage tree, so you can trace a recurring task back to the schedule behind it. That doesn’t set the task’s Origin, though: a schedule isn’t a member or a session, so a schedule-fired task’s Origin row reads Origin unknown.

The Tasks page Graph view

The Graph view on the Tasks page has its own Who filed toggle, which adds who created each visible task to its card — a lighter, workspace-wide view of the same fact the Origin row shows one task at a time.

Filed vs. worked

Beyond one task’s own story, CodeHerder can also tell you which tasks a member or a session touched, in two distinct ways:

• Filed — for a member, tasks their own credential created; for a session, tasks that session itself created.
• Worked — tasks that member’s sessions actually ran (or that one session ran), regardless of who filed them.

A human who files a lot of work but writes no code themselves might have many filed tasks and few worked ones; an agent tends to run the other way.

On the member, agent, and session pages

A member’s page and an agent’s page each show two panels, Tasks filed and Tasks worked. A session’s page shows Tasks filed in this session and Tasks worked.

From the CLI

ch member tasks [<ref>] --role filed|worked
ch session tasks [<sessionId>] --role filed|worked

--role is required — there’s no default, since “filed” and “worked” answer different questions and CodeHerder won’t guess which one you meant. Both commands page normally: 50 results at a time by default, up to 200, with --cursor to keep going.

There’s no separate ch agent tasks command — an agent is a member, so ch member tasks <agentRef> --role filed|worked covers agents too.

ch member show and ch agent show print filed and worked counts alongside the rest of the member’s fields, plus the ch member tasks command to see the full list. ch session show goes a step further and prints up to five of the session’s filed tasks directly, with a note on how to see the rest.

Related guides

• Finding and tracking your work — the Tasks page’s List, Board, and Graph views
• Activity feeds — the event-by-event record a task’s origin and lineage are drawn from
• Understanding the task hierarchy — the full rules behind the parent/child nesting that shows up as one of the connections in a task’s lineage
• Scheduled tasks — recurring tasks, including the ones that show up in a task’s lineage