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 or GitLab 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 its <Stage> session while working on <task>

Each clause — who filed it, the session it filed from, the task it was working on — appears only when CodeHerder recorded it, and the session clause names the stage the session was running (for example “its Code session”), not a session ID. A task an agent filed mid-session typically shows the whole sentence; a task you filed directly usually just names you.

When no member is recorded, the row names the kind instead: Filed by agent session, Filed by human, Filed by integration, or Filed by API. When a member is recorded and the kind isn’t a plain agent session, a small label follows their name (human, integration, API) so you can tell how they filed it. A task filed through an inbound webhook, for example, names the webhook’s acting member followed by an “integration” label.

Some tasks show Origin unknown instead. That’s expected, not an error. CodeHerder has no origin recorded for a task in three cases: a scheduled task that a schedule fired directly, a task made from Convert to task on a survey response, or a task 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; a larger value is treated as 6, the most CodeHerder will walk in one request.
• --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.

A schedule also keeps its own record of what each run filed. Open the schedule and look under Recent runs — see Scheduled tasks for what it shows and how to read it from the CLI.

The Tasks page Graph view

The Graph view on the Tasks page has its own Who filed toggle. Turning it on adds the member and session that filed each visible task as their own cards, connected to the task by a dashed arrow. It’s a lighter, workspace-wide view of the same fact the Origin row shows one task at a time. Whether or not that toggle is on, a dashed arrow also runs from a task to every other task it filed while it was being worked, when both are on screen. Solid arrows are dependencies, so the dashes tell the two apart.

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 history of a task, alongside its origin and lineage
• 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