The scanner records the actual git branch
The current build reads the branch directly from each repo during project scans, so branch state is not editorial copy. It is part of the product's observed delivery context.
Product note
Agent Harness already treats branch context as part of the product surface. The project scanner reads the active git branch, project cards expose it in the dashboard, and the workflow keeps a distinct review state. That matters because AI-assisted delivery becomes misleading fast when it describes progress without showing the lane where the work actually lives.
This note is based on what the product already does in code today, not on a future roadmap.
The current build reads the branch directly from each repo during project scans, so branch state is not editorial copy. It is part of the product's observed delivery context.
Each project card keeps the active branch beside task counts and last activity, which makes the lane visible before a reviewer opens the detail view.
The workflow already separates backlog, in-progress, review, and done. Branch visibility matters because review pressure only means something when teams know which lane the work lives on.
A project can be healthy on paper and still be risky if the visible work is happening on an outdated, exploratory, or release-bound branch. Delivery teams need that distinction before they trust AI-generated next steps.
When a task moves into review, the reviewer still needs to know which branch holds the implementation. Otherwise the system describes workflow state without showing the actual integration lane.
If an agent proposes follow-up work, release sequencing, or dependency cleanup without visible branch context, it can push a team toward the wrong code path with high confidence.
A dashboard should not imply that work is clean, current, or merge-ready unless the lane itself is visible. Branch context is one of the simplest ways to reduce false certainty in AI-assisted delivery.