Module work 

The working tree the HOME’s rows read, behind a cache: no render path shells out.

The session page’s own row is not here. That one is forge_workspace::work’s: the scan runs for a seat somebody is showing, and the row is pushed rather than read. This cache is the fleet’s - every project and agent row reads a branch and a change count as it renders - and a row is not worth a git subprocess per render.

Re-exports

use std::collections::HashMap; 🔒

use std::path::Path; 🔒

use std::path::PathBuf; 🔒

use std::sync::Arc; 🔒

use std::sync::Mutex; 🔒

use std::sync::MutexGuard; 🔒

use std::time::Duration; 🔒

use std::time::Instant; 🔒

use crate::git_diff; 🔒

use forge_primitives::SessionSlot; 🔒

Structs

Entry 🔒

WorkCache

Each session’s working tree, so a caller reads a value instead of spawning git per row per render.

WorkState

What one agent’s working tree looks like, and what git said about it.

Enums

Gate

The repo gate, as a view reads it. Its own type so the view does not have to name the scanner’s.

Constants

REFRESH_INTERVAL 🔒

How long a read answers for. Everything inside the window is served from the cache, which is what keeps a page render off a subprocess.

Functions

git_work_view

The tree behind a row’s depth, as both the record and its frames carry it: the two layers a row draws, with Clean and ScanFailed both reading as nothing to state - which is what the layer means, and the row above still carries the gate that says which.

read 🔒

One read of cwd. The count decides whether the directory is a repository at all: outside one both fields are None rather than an error or a stale branch, and the gate carries which of the two cases it was so the row can say so.

work_from_scan

The row a scan answers, from the scan and the directory it was taken of.