# Teamster guided-tour snapshot

**Status:** 13/13 queries succeeded
**Generated:** 2026-09-09 00:20:10 UTC

This is a periodic, read-only, pre-rendered copy of this demo's data
queries, normally run live via POST to

POST https://teamster.bmj.net/api/ds/query  (POST only — a GET returns 404)

published here for agents that can only issue GET requests. It regenerates
hourly; numbers are as of the timestamp above, not real-time. Every fenced
query below is reproduced exactly as it appears in its source document,

[https://teamster.bmj.net/public/llms/queries.txt](https://teamster.bmj.net/public/llms/queries.txt)

followed by its result at generation time. For what this data means — the
data model, tag vocabulary, and dashboard reference — see

[https://teamster.bmj.net/public/llms.txt](https://teamster.bmj.net/public/llms.txt)

**Before quoting any number below as fact:** most spend on this instance is
attributed after the fact by recovery passes, not declared by agents at the
time. The "Check whether the numbers are honest" step near the end of this
page (reproduced in full, not summarized) measures exactly how much — read
it before treating anything above it as precise.

---
# Teamster demo — the data queries

This document holds the queries that produce the demo's published numbers, each
with a note on what its result shape means. It is the source the data document
is generated from, so the two always agree.

**Meaning lives in the companion context guide:**
[https://teamster.bmj.net/public/llms.txt](https://teamster.bmj.net/public/llms.txt)
That document explains what Teamster is, what each tag dimension means, and how
to read these figures honestly. This one explains only what each query measures.

**Already-computed results, no query tool needed:**
[https://teamster.bmj.net/public/llms/tour-snapshot.txt](https://teamster.bmj.net/public/llms/tour-snapshot.txt)
Every query below, run against live data and refreshed hourly.

If you want to run these yourself rather than read the pre-computed results, you
need an HTTP client that can POST a JSON body; a GET-only fetcher cannot execute
them. The context guide's opening section says where to go instead.

Every window below is relative, so nothing here goes stale. The
`-- static-window:` comment on each query is an ordinary SQL comment declaring
whether the generator may widen that window when it publishes the data
document; it has no effect when the query runs.

---

## 1. What period this data covers

Everything else here is measured over a window, so this is the first thing
worth knowing: when the record starts, when it ends, and how much sits between.
The result is a single row. Read `days_covered` against the window any other
query uses — if a window reaches back further than the data does, it is asking
for time that does not exist and simply returns everything.

Density is not uniform across that span. The earliest days are thin, because
the system was being stood up and instrumented at the time, and the newest day
is always partial because it has not finished happening. The substantial data
sits between those two edges.

```sql
-- static-window: keep
SELECT MIN(timestamp)                           AS earliest,
       MAX(timestamp)                           AS latest,
       DATEDIFF(MAX(timestamp), MIN(timestamp)) AS days_covered,
       COUNT(*)                                 AS messages
FROM token_ledger

```

**Live result** (generated 2026-09-09 00:20:10 UTC):

| earliest | latest | days_covered | messages |
|---|---|---|---|
| 2026-04-25 18:03:27.690000 | 2026-09-08 16:29:59.320000 | 136 | 172373 |

## 2. Where the money goes, by product

The portfolio view: every product that carried spend in the window, ranked
by dollars, with its share and how many agent sessions touched it. An
`(untagged)` row appears alongside the named products — that is real spend on
work carrying no product tag, kept visible rather than filtered away.

Expect one product to dominate. On this instance that is Teamster itself, being
built by the agent teams it instruments. Dollars and sessions rank differently,
and the difference is informative: high spend across few sessions means long,
expensive sessions, which is a different situation from the same money spread
thinly across many.

```sql
-- static-window: full-history
WITH win AS (
  SELECT entity_type, entity_id, session_id, cost_usd
  FROM cost_facts
  WHERE timestamp >= (SELECT MIN(timestamp) FROM token_ledger)
),
lens AS (
  SELECT r.entity_type, r.entity_id, MIN(t.tag_value) AS tag_value
  FROM entity_tags_resolved r
  JOIN tags t ON t.id = r.tag_id
  WHERE t.tag_key = 'product'
  GROUP BY r.entity_type, r.entity_id
)
SELECT COALESCE(l.tag_value, '(untagged)') AS tag_value,
       ROUND(SUM(w.cost_usd), 2)           AS usd,
       ROUND(100 * SUM(w.cost_usd) / SUM(SUM(w.cost_usd)) OVER (), 1) AS pct_of_window,
       COUNT(DISTINCT w.session_id)        AS sessions
FROM win w
LEFT JOIN lens l
  ON l.entity_type = w.entity_type AND l.entity_id = w.entity_id
GROUP BY 1
ORDER BY usd DESC
LIMIT 50
```

*(This fence declares `static-window: full-history`: its relative window has been widened to the anchor shown above so this page reflects full data history. The copy-paste version of this query in the live guide keeps the original recent window unchanged.)*

**Live result** (generated 2026-09-09 00:20:10 UTC):

| tag_value | usd | pct_of_window | sessions |
|---|---|---|---|
| Teamster | 18321.65 | 68.0 | 492 |
| teamster-demo | 1975.46 | 7.3 | 28 |
| worthwhale | 1408.74 | 5.2 | 6 |
| TradeWars | 1283.49 | 4.8 | 5 |
| anchor | 911.77 | 3.4 | 37 |
| ScrollZ | 687.68 | 2.6 | 3 |
| homelab | 642.21 | 2.4 | 48 |
| teamsters-union | 541.53 | 2.0 | 3 |
| (untagged) | 380.56 | 1.4 | 45 |
| muster | 292.75 | 1.1 | 3 |
| teamster-manager | 166.53 | 0.6 | 11 |
| pibox | 150.99 | 0.6 | 1 |
| job-search | 68.18 | 0.3 | 6 |
| helmsman | 68.15 | 0.3 | 2 |
| procps | 20.04 | 0.1 | 1 |
| sb | 14.07 | 0.1 | 1 |
| PizzaLab | 9.09 | 0.0 | 13 |

## 3. What kind of work the money bought

The same money, re-sliced by what was being done rather than what it was
done to. This query is the previous one with a single string changed —
`'product'` becomes `'work-type'` — which is the whole idea: one shape, many
lenses.

The headline read is the balance between making (`feature`, `refactor`),
repairing (`bug`, `rework`) and finding out (`research`, `test`). A portfolio
heavy on `feature` is being extended; one heavy on `bug` is being held
together. The work-type dictionary in the context guide defines each value
precisely, and those definitions carry deliberate exclusions worth reading
before interpreting the split.

Note that a work type can be small in dollars but present in a great many
sessions. That pattern means a pervasive small tax rather than a big project.

```sql
-- static-window: full-history
WITH win AS (
  SELECT entity_type, entity_id, session_id, cost_usd
  FROM cost_facts
  WHERE timestamp >= (SELECT MIN(timestamp) FROM token_ledger)
),
lens AS (
  SELECT r.entity_type, r.entity_id, MIN(t.tag_value) AS tag_value
  FROM entity_tags_resolved r
  JOIN tags t ON t.id = r.tag_id
  WHERE t.tag_key = 'work-type'
  GROUP BY r.entity_type, r.entity_id
)
SELECT COALESCE(l.tag_value, '(untagged)') AS tag_value,
       ROUND(SUM(w.cost_usd), 2)           AS usd,
       ROUND(100 * SUM(w.cost_usd) / SUM(SUM(w.cost_usd)) OVER (), 1) AS pct_of_window,
       COUNT(DISTINCT w.session_id)        AS sessions
FROM win w
LEFT JOIN lens l
  ON l.entity_type = w.entity_type AND l.entity_id = w.entity_id
GROUP BY 1
ORDER BY usd DESC
LIMIT 50
```

*(This fence declares `static-window: full-history`: its relative window has been widened to the anchor shown above so this page reflects full data history. The copy-paste version of this query in the live guide keeps the original recent window unchanged.)*

**Live result** (generated 2026-09-09 00:20:10 UTC):

| tag_value | usd | pct_of_window | sessions |
|---|---|---|---|
| feature | 10579.42 | 39.3 | 180 |
| bug | 5037.80 | 18.7 | 134 |
| research | 4330.53 | 16.1 | 172 |
| docs | 2101.48 | 7.8 | 65 |
| test | 1241.43 | 4.6 | 97 |
| refactor | 955.23 | 3.5 | 33 |
| infra | 854.51 | 3.2 | 55 |
| (untagged) | 519.46 | 1.9 | 202 |
| investigation | 511.68 | 1.9 | 32 |
| admin | 411.27 | 1.5 | 82 |
| design-review | 334.72 | 1.2 | 2 |
| polish | 51.29 | 0.2 | 2 |
| bugfix | 14.07 | 0.1 | 1 |

## 4. Where in the lifecycle the money fell

Phase says whether work went smoothly. `build` is normally the largest
value, followed by some ordering of `review`, `rework`, `design` and `test`,
plus a few values that predate the current vocabulary.

This is the breakdown Teamster exists to expose. Add `review` and `rework`
together and divide by `build`: that is what verification and correction cost
as a fraction of first-pass production. There is no universal good number, but
the direction of travel matters far more than the level, and a `rework` share
climbing while `build` stays flat is the signal — quality or briefing problems
showing up in the budget before they show up in a slipped date.

```sql
-- static-window: full-history
WITH win AS (
  SELECT entity_type, entity_id, session_id, cost_usd
  FROM cost_facts
  WHERE timestamp >= (SELECT MIN(timestamp) FROM token_ledger)
),
lens AS (
  SELECT r.entity_type, r.entity_id, MIN(t.tag_value) AS tag_value
  FROM entity_tags_resolved r
  JOIN tags t ON t.id = r.tag_id
  WHERE t.tag_key = 'phase'
  GROUP BY r.entity_type, r.entity_id
)
SELECT COALESCE(l.tag_value, '(untagged)') AS tag_value,
       ROUND(SUM(w.cost_usd), 2)           AS usd,
       ROUND(100 * SUM(w.cost_usd) / SUM(SUM(w.cost_usd)) OVER (), 1) AS pct_of_window,
       COUNT(DISTINCT w.session_id)        AS sessions
FROM win w
LEFT JOIN lens l
  ON l.entity_type = w.entity_type AND l.entity_id = w.entity_id
GROUP BY 1
ORDER BY usd DESC
LIMIT 50
```

*(This fence declares `static-window: full-history`: its relative window has been widened to the anchor shown above so this page reflects full data history. The copy-paste version of this query in the live guide keeps the original recent window unchanged.)*

**Live result** (generated 2026-09-09 00:20:10 UTC):

| tag_value | usd | pct_of_window | sessions |
|---|---|---|---|
| build | 15973.77 | 59.3 | 476 |
| design | 3061.46 | 11.4 | 142 |
| review | 2468.60 | 9.2 | 104 |
| test | 1953.92 | 7.3 | 97 |
| iterate | 1328.07 | 4.9 | 33 |
| research | 931.74 | 3.5 | 23 |
| investigate | 604.55 | 2.2 | 46 |
| (untagged) | 290.22 | 1.1 | 43 |
| admin | 182.49 | 0.7 | 2 |
| exec | 107.54 | 0.4 | 18 |
| implementation | 40.53 | 0.2 | 4 |

## 5. Whether correction cost is rising

The same phase data as a trend rather than a total, bucketed by week, so
the direction is visible instead of a single blended number.

Read the percentage column next to the build column, never alone. In a quiet
week it is a ratio of two small numbers and will produce absurd values — several
hundred percent, or zero — whenever build spend is near nothing. The weeks that
carry meaning are the busy ones; that is where a rising correction share is
real.

```sql
-- static-window: full-history
WITH win AS (
  SELECT entity_type, entity_id, timestamp, cost_usd
  FROM cost_facts
  WHERE timestamp >= (SELECT MIN(timestamp) FROM token_ledger)
),
lens AS (
  SELECT r.entity_type, r.entity_id, MIN(t.tag_value) AS tag_value
  FROM entity_tags_resolved r
  JOIN tags t ON t.id = r.tag_id
  WHERE t.tag_key = 'phase'
  GROUP BY r.entity_type, r.entity_id
)
SELECT DATE(w.timestamp - INTERVAL WEEKDAY(w.timestamp) DAY) AS week_starting,
       ROUND(SUM(CASE WHEN l.tag_value = 'build' THEN w.cost_usd ELSE 0 END), 2) AS build_usd,
       ROUND(SUM(CASE WHEN l.tag_value IN ('review','rework') THEN w.cost_usd ELSE 0 END), 2) AS review_rework_usd,
       ROUND(100 * SUM(CASE WHEN l.tag_value IN ('review','rework') THEN w.cost_usd ELSE 0 END)
             / NULLIF(SUM(CASE WHEN l.tag_value = 'build' THEN w.cost_usd ELSE 0 END), 0), 1) AS pct_of_build
FROM win w
LEFT JOIN lens l
  ON l.entity_type = w.entity_type AND l.entity_id = w.entity_id
GROUP BY 1
ORDER BY 1
LIMIT 200
```

*(This fence declares `static-window: full-history`: its relative window has been widened to the anchor shown above so this page reflects full data history. The copy-paste version of this query in the live guide keeps the original recent window unchanged.)*

**Live result** (generated 2026-09-09 00:20:10 UTC):

| week_starting | build_usd | review_rework_usd | pct_of_build |
|---|---|---|---|
| 2026-04-20 | 0.00 | 0.00 | NULL |
| 2026-04-27 | 0.00 | 0.00 | NULL |
| 2026-05-04 | 0.00 | 0.00 | NULL |
| 2026-05-11 | 30.31 | 0.00 | 0.0 |
| 2026-05-18 | 657.36 | 1.03 | 0.2 |
| 2026-05-25 | 1758.24 | 1.24 | 0.1 |
| 2026-06-01 | 1230.02 | 224.71 | 18.3 |
| 2026-06-08 | 1605.81 | 440.21 | 27.4 |
| 2026-06-15 | 717.83 | 95.97 | 13.4 |
| 2026-06-22 | 406.22 | 101.97 | 25.1 |
| 2026-06-29 | 47.01 | 49.61 | 105.5 |
| 2026-07-06 | 2345.51 | 656.22 | 28.0 |
| 2026-07-13 | 910.86 | 173.40 | 19.0 |
| 2026-07-20 | 2.31 | 66.81 | 2891.5 |
| 2026-07-27 | 141.06 | 84.99 | 60.3 |
| 2026-08-03 | 433.54 | 0.00 | 0.0 |
| 2026-08-10 | 494.31 | 238.82 | 48.3 |
| 2026-08-17 | 1617.98 | 132.36 | 8.2 |
| 2026-08-24 | 484.70 | 37.51 | 7.7 |
| 2026-08-31 | 2836.80 | 163.77 | 5.8 |
| 2026-09-07 | 253.88 | 0.00 | 0.0 |

## 6. Which products are being built and which are being repaired

Two dimensions crossed. Each product's work-type mix, with the percentage
normalised within that product so a small effort and a large one are directly
comparable.

This is where a portfolio acquires character. Two products with identical
totals can have completely different mixes — one almost entirely `feature`,
another split across `test`, `refactor`, `bug` and `admin`. The first is being
extended; the second is being maintained, hardened, or rescued. Neither is
wrong, but they are different activities, and a single spend number cannot tell
them apart.

```sql
-- static-window: full-history
WITH win AS (
  SELECT entity_type, entity_id, cost_usd
  FROM cost_facts
  WHERE timestamp >= (SELECT MIN(timestamp) FROM token_ledger)
),
prod AS (
  SELECT r.entity_type, r.entity_id, MIN(t.tag_value) AS tag_value
  FROM entity_tags_resolved r
  JOIN tags t ON t.id = r.tag_id
  WHERE t.tag_key = 'product'
  GROUP BY r.entity_type, r.entity_id
),
kind AS (
  SELECT r.entity_type, r.entity_id, MIN(t.tag_value) AS tag_value
  FROM entity_tags_resolved r
  JOIN tags t ON t.id = r.tag_id
  WHERE t.tag_key = 'work-type'
  GROUP BY r.entity_type, r.entity_id
)
SELECT COALESCE(p.tag_value, '(untagged)') AS product,
       COALESCE(k.tag_value, '(untagged)') AS work_type,
       ROUND(SUM(w.cost_usd), 2)           AS usd,
       ROUND(100 * SUM(w.cost_usd)
             / SUM(SUM(w.cost_usd)) OVER (PARTITION BY COALESCE(p.tag_value, '(untagged)')), 1) AS pct_of_product
FROM win w
LEFT JOIN prod p ON p.entity_type = w.entity_type AND p.entity_id = w.entity_id
LEFT JOIN kind k ON k.entity_type = w.entity_type AND k.entity_id = w.entity_id
GROUP BY 1, 2
HAVING usd >= 1
ORDER BY product, usd DESC
LIMIT 300
```

*(This fence declares `static-window: full-history`: its relative window has been widened to the anchor shown above so this page reflects full data history. The copy-paste version of this query in the live guide keeps the original recent window unchanged.)*

**Live result** (generated 2026-09-09 00:20:10 UTC):

| product | work_type | usd | pct_of_product |
|---|---|---|---|
| (untagged) | (untagged) | 291.53 | 76.6 |
| (untagged) | feature | 43.31 | 11.4 |
| (untagged) | investigation | 20.29 | 5.3 |
| (untagged) | bugfix | 14.07 | 3.7 |
| (untagged) | refactor | 8.88 | 2.3 |
| (untagged) | design-review | 2.49 | 0.7 |
| anchor | feature | 579.85 | 63.6 |
| anchor | research | 329.75 | 36.2 |
| anchor | infra | 1.72 | 0.2 |
| helmsman | feature | 45.51 | 66.8 |
| helmsman | research | 21.04 | 30.9 |
| helmsman | test | 1.59 | 2.3 |
| homelab | bug | 205.03 | 31.9 |
| homelab | feature | 166.48 | 25.9 |
| homelab | admin | 110.53 | 17.2 |
| homelab | infra | 64.09 | 10.0 |
| homelab | research | 54.84 | 8.5 |
| homelab | docs | 27.05 | 4.2 |
| homelab | refactor | 8.24 | 1.3 |
| homelab | (untagged) | 3.42 | 0.5 |
| homelab | investigation | 2.53 | 0.4 |
| job-search | feature | 31.26 | 45.8 |
| job-search | docs | 28.15 | 41.3 |
| job-search | research | 8.77 | 12.9 |
| muster | feature | 257.49 | 88.0 |
| muster | bug | 19.41 | 6.6 |
| muster | research | 8.50 | 2.9 |
| muster | (untagged) | 7.35 | 2.5 |
| pibox | feature | 100.76 | 66.7 |
| pibox | docs | 50.23 | 33.3 |
| PizzaLab | test | 6.00 | 67.4 |
| PizzaLab | feature | 2.91 | 32.6 |
| procps | feature | 19.95 | 100.0 |
| sb | feature | 8.41 | 60.4 |
| sb | research | 5.52 | 39.6 |
| ScrollZ | feature | 155.31 | 22.6 |
| ScrollZ | research | 149.67 | 21.8 |
| ScrollZ | refactor | 126.47 | 18.4 |
| ScrollZ | bug | 115.76 | 16.8 |
| ScrollZ | admin | 82.53 | 12.0 |
| ScrollZ | test | 57.94 | 8.4 |
| Teamster | feature | 6206.56 | 33.9 |
| Teamster | bug | 4113.87 | 22.5 |
| Teamster | research | 2833.74 | 15.5 |
| Teamster | docs | 1502.62 | 8.2 |
| Teamster | test | 986.70 | 5.4 |
| Teamster | refactor | 811.89 | 4.4 |
| Teamster | infra | 658.17 | 3.6 |
| Teamster | investigation | 455.67 | 2.5 |
| Teamster | design-review | 332.24 | 1.8 |
| Teamster | admin | 216.79 | 1.2 |
| Teamster | (untagged) | 188.66 | 1.0 |
| Teamster | polish | 14.74 | 0.1 |
| teamster-demo | feature | 1056.09 | 53.5 |
| teamster-demo | docs | 340.48 | 17.2 |
| teamster-demo | research | 223.22 | 11.3 |
| teamster-demo | bug | 174.61 | 8.8 |
| teamster-demo | infra | 124.07 | 6.3 |
| teamster-demo | test | 32.97 | 1.7 |
| teamster-demo | investigation | 14.52 | 0.7 |
| teamster-demo | (untagged) | 5.24 | 0.3 |
| teamster-demo | refactor | 2.98 | 0.2 |
| teamster-demo | admin | 1.29 | 0.1 |
| teamster-manager | feature | 67.50 | 40.6 |
| teamster-manager | bug | 47.75 | 28.7 |
| teamster-manager | (untagged) | 23.26 | 14.0 |
| teamster-manager | research | 16.02 | 9.6 |
| teamster-manager | refactor | 11.68 | 7.0 |
| teamsters-union | feature | 530.94 | 98.0 |
| teamsters-union | docs | 10.59 | 2.0 |
| TradeWars | research | 774.18 | 60.3 |
| TradeWars | feature | 433.60 | 33.8 |
| TradeWars | docs | 70.06 | 5.5 |
| TradeWars | bug | 5.64 | 0.4 |
| worthwhale | feature | 940.16 | 66.7 |
| worthwhale | bug | 204.81 | 14.5 |
| worthwhale | investigation | 189.85 | 13.5 |
| worthwhale | polish | 36.55 | 2.6 |
| worthwhale | test | 28.05 | 2.0 |
| worthwhale | docs | 8.26 | 0.6 |
| worthwhale | research | 1.06 | 0.1 |

## 7. Which individual efforts cost the most

Work-scope slugs name one specific piece of work — `feature:<name>`,
`bug:<name>`, `research:<name>`. The set changes constantly, so it is
discovered rather than assumed; this query ranks the live ones by spend.

The top entries are usually large multi-week features or deep research pushes,
and cost falls off quickly down the list. The slug key tells you what kind of
work each one was.

```sql
-- static-window: full-history
WITH win AS (
  SELECT entity_type, entity_id, session_id, cost_usd
  FROM cost_facts
  WHERE timestamp >= (SELECT MIN(timestamp) FROM token_ledger)
),
scope AS (
  SELECT r.entity_type, r.entity_id,
         CONCAT(t.tag_key, ':', t.tag_value) AS slug
  FROM entity_tags_resolved r
  JOIN tags t ON t.id = r.tag_id
  WHERE t.tag_key IN ('feature','bug','refactor','infra','research','docs','test','admin','rework')
)
SELECT s.slug,
       ROUND(SUM(w.cost_usd), 2)    AS usd,
       COUNT(DISTINCT w.session_id) AS sessions
FROM win w
JOIN scope s ON s.entity_type = w.entity_type AND s.entity_id = w.entity_id
GROUP BY s.slug
ORDER BY usd DESC
LIMIT 15
```

*(This fence declares `static-window: full-history`: its relative window has been widened to the anchor shown above so this page reflects full data history. The copy-paste version of this query in the live guide keeps the original recent window unchanged.)*

**Live result** (generated 2026-09-09 00:20:10 UTC):

| slug | usd | sessions |
|---|---|---|
| feature:wms-hygiene | 3937.30 | 6 |
| feature:agent-health | 1093.32 | 3 |
| research:llm-experiment | 886.56 | 2 |
| feature:codex-support | 807.20 | 2 |
| feature:nick-colorizer | 657.47 | 2 |
| bug:codex-deferred-tool-discovery | 647.26 | 1 |
| feature:anchor-telemetry | 561.70 | 2 |
| feature:monitoring | 554.45 | 7 |
| feature:cost-attribution | 550.78 | 11 |
| feature:wms-hygiene-kit | 531.61 | 1 |
| feature:anchor | 517.42 | 29 |
| feature:teamster-clone | 502.55 | 2 |
| docs:teamsters-union-kit | 456.30 | 1 |
| docs:agent-guide | 454.80 | 2 |
| refactor:persistence-api | 386.11 | 1 |

## 8. How much that top list hides

Any top-N list is a truncation, and on this dimension the truncation is
most of the story. This buckets the same spend three ways: the ranked slugs
shown above, everything below them, and spend carrying no work-scope tag at all.

Over a recent window the top entries look like a comfortable majority. Widened
to the full record that collapses — the top fifteen fall to roughly two fifths
of all spend, with a comparable amount spread across the remaining slugs and
close to a quarter carrying no work-scope tag whatsoever. The list is not
wrong, but reading it as "where the money went" would be, and the longer the
window the more wrong it gets.

The third bucket exists only because this query uses a `LEFT JOIN`. The ranking
above inner-joins to the slug tags, which structurally cannot show spend
carrying none. A truncated list can at least be suspected; an inner join's
omissions are invisible. That is worth remembering for any tag filter anywhere
in this dataset.

```sql
-- static-window: full-history
WITH win AS (
  SELECT entity_type, entity_id, cost_usd
  FROM cost_facts
  WHERE timestamp >= (SELECT MIN(timestamp) FROM token_ledger)
),
scope AS (
  SELECT r.entity_type, r.entity_id,
         MIN(CONCAT(t.tag_key, ':', t.tag_value)) AS slug
  FROM entity_tags_resolved r
  JOIN tags t ON t.id = r.tag_id
  WHERE t.tag_key IN ('feature','bug','refactor','infra','research','docs','test','admin','rework')
  GROUP BY r.entity_type, r.entity_id
)
SELECT bucket,
       ROUND(SUM(usd), 2)                               AS usd,
       ROUND(100 * SUM(usd) / SUM(SUM(usd)) OVER (), 1) AS pct_of_all_spend
FROM (
  SELECT usd,
         CASE WHEN slug IS NULL THEN '3. no work-scope tag at all'
              WHEN rn <= 15     THEN '1. top 15 slugs (the table above)'
              ELSE                   '2. all other slugs'          END AS bucket
  FROM (
    SELECT s.slug,
           SUM(w.cost_usd) AS usd,
           CASE WHEN s.slug IS NULL THEN NULL
                ELSE ROW_NUMBER() OVER (PARTITION BY CASE WHEN s.slug IS NULL THEN 1 ELSE 0 END
                                        ORDER BY SUM(w.cost_usd) DESC) END AS rn
    FROM win w
    LEFT JOIN scope s ON s.entity_type = w.entity_type AND s.entity_id = w.entity_id
    GROUP BY s.slug
  ) ranked
) bucketed
GROUP BY bucket
ORDER BY bucket
LIMIT 10
```

*(This fence declares `static-window: full-history`: its relative window has been widened to the anchor shown above so this page reflects full data history. The copy-paste version of this query in the live guide keeps the original recent window unchanged.)*

**Live result** (generated 2026-09-09 00:20:10 UTC):

| bucket | usd | pct_of_all_spend |
|---|---|---|
| 1. top 15 slugs (the table above) | 12120.03 | 45.0 |
| 2. all other slugs | 8851.62 | 32.9 |
| 3. no work-scope tag at all | 5971.24 | 22.2 |

## 9. What one effort actually consisted of

The drill-down: everything booked against the single most expensive effort,
broken into its outcomes and work units with each one's title, phase and cost.
The query finds the top slug itself rather than naming one, so it stays correct
as the data moves.

Read top to bottom and the result is the narrative of a piece of engineering
work — the design pass, the numbered work packages, the fixes that came back,
the verification runs, the final review. This is the join the product exists to
make: titles from the work records, dollars from the cost table, phase from the
tags. It is what a bill and a commit log cannot tell you between them.

```sql
-- static-window: full-history
WITH win AS (
  SELECT entity_type, entity_id, session_id, cost_usd
  FROM cost_facts
  WHERE timestamp >= (SELECT MIN(timestamp) FROM token_ledger)
),
scope AS (
  SELECT r.entity_type, r.entity_id,
         CONCAT(t.tag_key, ':', t.tag_value) AS slug
  FROM entity_tags_resolved r
  JOIN tags t ON t.id = r.tag_id
  WHERE t.tag_key IN ('feature','bug','refactor','infra','research','docs','test','admin','rework')
),
ph_map AS (
  SELECT r.entity_type, r.entity_id, MIN(t.tag_value) AS tag_value
  FROM entity_tags_resolved r
  JOIN tags t ON t.id = r.tag_id
  WHERE t.tag_key = 'phase'
  GROUP BY r.entity_type, r.entity_id
),
top_slug AS (
  SELECT s.slug
  FROM win w
  JOIN scope s ON s.entity_type = w.entity_type AND s.entity_id = w.entity_id
  GROUP BY s.slug
  ORDER BY SUM(w.cost_usd) DESC
  LIMIT 1
)
SELECT s.slug,
       w.entity_type,
       COALESCE(o.title, u.title, w.entity_id)  AS work_item,
       COALESCE(ph.tag_value, '(unphased)')     AS phase,
       ROUND(SUM(w.cost_usd), 2)                AS usd,
       COUNT(DISTINCT w.session_id)             AS sessions
FROM win w
JOIN scope s     ON s.entity_type = w.entity_type AND s.entity_id = w.entity_id
JOIN top_slug ts ON ts.slug = s.slug
LEFT JOIN ph_map ph ON ph.entity_type = w.entity_type AND ph.entity_id = w.entity_id
LEFT JOIN outcomes  o ON w.entity_type = 'outcome'  AND o.id = w.entity_id
LEFT JOIN workunits u ON w.entity_type = 'workunit' AND u.id = w.entity_id
GROUP BY 1, 2, 3, 4
ORDER BY usd DESC
LIMIT 200
```

*(This fence declares `static-window: full-history`: its relative window has been widened to the anchor shown above so this page reflects full data history. The copy-paste version of this query in the live guide keeps the original recent window unchanged.)*

**Live result** (generated 2026-09-09 00:20:10 UTC):

| slug | entity_type | work_item | phase | usd | sessions |
|---|---|---|---|---|---|
| feature:wms-hygiene | outcome | WMS hygiene Train 2: stale-work sweep (WP3/WP4/WP6), MCP call-volume ledger (WP11 §2/WP12), and the accepted-session gaps, on wt/wms-hygiene = the v0.2.8 line | build | 551.66 | 3 |
| feature:wms-hygiene | outcome | WMS hygiene Train 2 closing phase (#daybreak): chunk live-fire at ea5280d, supervisor units, docs residuals, WP4, WP11 §2/WP12, acceptance → release/v0.2.8 | build | 421.56 | 2 |
| feature:wms-hygiene | workunit | Stop draining focus intervals on every Stop event: close on staleness instead, keep the roster's closed tier alive, and recover the claim identity hookd already has (HOOKD-DRAIN.md Option A + claim path) | test | 265.43 | 1 |
| feature:wms-hygiene | workunit | WP3 proactive review sweep — design rewrite as a document, red-teamed before any code | build | 208.32 | 1 |
| feature:wms-hygiene | workunit | Give the otelcol/prometheus/grafana supervisor group systemd units so it survives a reboot (today it is bare nohup processes under `teamster start` with no reboot-survival mechanism) | test | 188.54 | 2 |
| feature:wms-hygiene | outcome | Evaluate the WMS hygiene kit (#17/#11) and implement the accepted path on release/v0.2.7 | build | 158.02 | 1 |
| feature:wms-hygiene | workunit | Fix LF-gfx-1: the engine clears the `resolution` tag on the done→review reopen edge (journaled via RecordMutation) so an abandoned-after-reopen Outcome no longer asserts "achieved" | build | 146.44 | 1 |
| feature:wms-hygiene | outcome | Prove the four live-fire fixes on chunk at 236ea6a, obtain operator acceptance of Train 1, and fold wt/wms-hygiene into release/v0.2.8 | build | 145.73 | 1 |
| feature:wms-hygiene | workunit | Implement the single prose pass: WP1, WP1b, WP8, WP12 A/B, WP5 as decision record, and every stale-doc seam the scouts enumerated | test | 125.85 | 1 |
| feature:wms-hygiene | workunit | installrunner re-installs and re-enables teamster-sweep.timer / teamster-backup.timer over the masks `teamster clone` set on a disposable target — an in-place upgrade on a clone silently restarts hourly paid `claude --print` runs | build | 97.91 | 1 |
| feature:wms-hygiene | workunit | Sweep docs pass: config keys, timer, CLI, on_hold/reopen semantics, the rule-id family, resolution:swept-unreviewed, burn-in procedure — every prose home, both plugin mirrors | build | 95.16 | 1 |
| feature:wms-hygiene | workunit | Implement MCP-handler slice: permanent last-sibling nudge, terminal-Outcome create guard, WP9 descriptions, WP10 notes, WP2 array tags | test | 91.98 | 1 |
| feature:wms-hygiene | workunit | Investigate: after a plain reboot of an upgraded clone target, teamster-hookd.service came back disabled/inactive and the supervisor group was not running, while every other unit came back enabled — installer gap or clone-target design? | build | 84.84 | 1 |
| feature:wms-hygiene | workunit | Reaper phase 3: do not stale-close an in-process teammate whose lead session is live (sweep-scoped exemption, both backends) + make the focus nudge open-interval-aware | build | 84.63 | 2 |
| feature:wms-hygiene | workunit | wms-mcp tool honesty pass: claim response, setPhase gating and error semantics, redelivery in review, FK error leak, resolution in the tag manifest | build | 79.06 | 1 |
| feature:wms-hygiene | outcome | Live-fire Train 1 of the WMS hygiene kit on chunk, fix defects, and fold wt/wms-hygiene into release/v0.2.8 | build | 78.08 | 1 |
| feature:wms-hygiene | workunit | WP11 §2 — events.jsonl tailer + mcp_tool_calls ledger (new oneshot binary + timer, cursor with copytruncate guard, keyed on session_full); design note first; GATED on wh2-supervisor-systemd-units landing | build | 65.81 | 2 |
| feature:wms-hygiene | workunit | Implement the proactive review sweep per WP3-DESIGN.md (two-stage via on_hold): command, store queries, timer, gauge notification, smoketest scenario | test | 63.53 | 1 |
| feature:wms-hygiene | workunit | Chunk live-fire of the v0.2.8 line at fe31320: upgrade on cloned plex data, the sweep's first real dry-run listing, the timer, the gauge, and the stop-drain proof (teammate intervals survive a lead's turn boundary) | review | 63.51 | 1 |
| feature:wms-hygiene | workunit | teamster stop falls through to killByPort and SIGKILLs a systemd-managed process behind systemd's back, racing Restart=on-failure — pre-existing for hookd at HEAD, and the shape the supervisor units would inherit | build | 52.53 | 2 |
| feature:wms-hygiene | workunit | Fix LF-skills-1 and LF-VER-4: resolve the 9a/9b close-out re-ask contradiction (Option A) in both the Claude and Codex mirrors, restore the missing Codex parenthetical, and correct the `component` cardinality statement | review | 48.51 | 1 |
| feature:wms-hygiene | workunit | installrunner.sh stage-only "wire manually" help text still tells the operator to sudo-install the hookd unit into /etc/systemd/system with no mask check — printed advice that overwrites a hand-masked hookd (2f59a23's guard covers executed paths only) | build | 47.98 | 1 |
| feature:wms-hygiene | workunit | WP4 — Sweep Report Grafana dashboard (skel/etc/grafana/dashboards/sweep-report.json), queries corrected against the shipped wms-review-sweep journal grammar; live ACs gated on chunk's confirmed run | build | 45.94 | 1 |
| feature:wms-hygiene | workunit | otelcol: one argument builder with two callers (StartOtelcol and the --exec path) and a test that asserts against it — the same shape the supervisor commit gave prometheus and grafana | build | 42.04 | 1 |
| feature:wms-hygiene | workunit | Fix LF-CLI-2: `wms gc` phase 4 must close the intervals of the entities it just abandoned (CloseIntervalsOnTerminalEntities after closeStaleEntities) | build | 41.73 | 1 |
| feature:wms-hygiene | workunit | docs/quickstart.md burn-in step tells the operator to sudo-install the review-sweep unit files and enable --now — on a clone target that destroys the mask maskDisposableTimers set and enables the unit that autonomously abandons entities | build | 40.99 | 1 |
| feature:wms-hygiene | workunit | WP6 one-time legacy drain runbook: enumeration queries, per-population dispositions, the close loop, ordering before the sweep's Confirm flip, chunk rehearsal plan, plex execution steps | build | 39.79 | 1 |
| feature:wms-hygiene | workunit | Implement server/telemetry slice: abandoned-aware interval close, full session id in the JSONL record and in wms backfill, logrotate path | test | 39.70 | 1 |
| feature:wms-hygiene | workunit | Docs residuals from wave 2: docs/clone.md note for the installer mask guard (2f59a23) and a quickstart burn-in pointer to the WP6 legacy-drain runbook (drafted, pending the operator's ruling on where the runbook lives) | review | 35.87 | 1 |
| feature:wms-hygiene | workunit | Implement WP7 cascade removal, WP9 state-machine core, WP10 core + path 4 in internal/wms | test | 35.85 | 1 |
| feature:wms-hygiene | workunit | teamster status: render StatusSummary.OutcomesOnHold / WorkUnitsOnHold as their own line when nonzero (WP3-DESIGN §3a file-plan item missed by wh2-wp3-impl) | build | 35.80 | 1 |
| feature:wms-hygiene | workunit | Implement WP9 store layer: migrations, SQL terminal-status sites, GetStatusSummary bucket, map/table cross-check test | build | 33.67 | 1 |
| feature:wms-hygiene | workunit | Chunk cycle 4: in-place upgrade to 4afe7aa — the three supervisor units survive a reboot (live proof for wh2-supervisor-systemd-units), the Sweep Report dashboard loads and its panels run on chunk's rows, masks still hold | build | 27.39 | 1 |
| feature:wms-hygiene | workunit | Implement WP9 Grafana audit and edits: status colour maps and completion/open-rate panels across seven dashboards | build | 27.08 | 1 |
| feature:wms-hygiene | workunit | hookd: close-out warnings queued for the sweep's fixed non-live session id (wms-review-sweep) never drain — unbounded wmsWarningQueue growth per confirmed run | test | 24.07 | 1 |
| feature:wms-hygiene | workunit | Independent opus verification of the four live-fire deliverables on chunk (re-run a sample, check quoted evidence exists, challenge PASS claims) | test | 23.71 | 1 |
| feature:wms-hygiene | workunit | Fix LF-CLI-1: `teamster wms close` must validate the entity's current status against the engine's transition table before writing (reject already-terminal and done→abandoned) | build | 22.21 | 1 |
| feature:wms-hygiene | workunit | Make hookd's close-out required-tags warning inheritance-aware (server.go:1571 reads direct tags only) | test | 22.00 | 1 |
| feature:wms-hygiene | workunit | Docs pass for wave 2: attribution semantics after the Stop-drain fix, claim wording at nine "atomically" sites, ritualManaged in the manifest docs, teammate-guide whitespace rule, Codex mirror state-machine section | build | 17.42 | 1 |
| feature:wms-hygiene | workunit | Investigate hookd's per-turn Stop handler draining every open focus interval — mechanism, blast radius, fix options | test | 17.08 | 1 |
| feature:wms-hygiene | workunit | Re-run LF-CLI-1 and LF-CLI-2 on chunk at 236ea6a (wms close transition guard; gc phase-5 interval drain) | build | 15.60 | 1 |
| feature:wms-hygiene | workunit | Chunk live-fire of the v0.2.8 line at ea5280d under the operator's grants: in-place upgrade, masks survive (2f59a23), reboot → hookd enabled (ea5280d), real nested-claude stop-drain proof, --confirm on lf2-* fixtures for AC8/AC10-12 | build | 14.36 | 2 |
| feature:wms-hygiene | workunit | Implement CLI slice: wms close/gc abandoned semantics, WP10 journal paths 2/3, wms list filter, status summary surface, setup-wizard resolution text | test | 13.01 | 1 |
| feature:wms-hygiene | workunit | Docs-on-fold audit: make sure user and dev docs reflect the seven post-6436eef commits (wms close rejections, gc phase 5, reopen clears resolution, journal read ordering, close-out Option A) | build | 12.98 | 1 |
| feature:wms-hygiene | workunit | Fold wt/wms-hygiene (236ea6a) into release/v0.2.8 after explicit operator acceptance and once the branch exists (PR #24 merged) | build | 12.70 | 1 |
| feature:wms-hygiene | workunit | Fix LF-VER-RR-2: journal history ordering gets an id tiebreak (ORDER BY created_at DESC, id DESC) in both store backends so same-second rows keep cause-before-effect | test | 12.24 | 1 |
| feature:wms-hygiene | workunit | Live-fire on chunk: WP8 deliberate close-out in a real Claude Code session (reason-recommend-ask instead of auto-close), driven via session-explorer | iterate | 11.71 | 1 |
| feature:wms-hygiene | workunit | Scout: re-measure the stale-entity symptom on the live hub (read-only SQL) against the kit baseline | build | 10.62 | 1 |
| feature:wms-hygiene | workunit | Live-fire acceptance of Train 1 on the chunk VM: clone plex data, materialize wt/wms-hygiene, run the ACs after the operator's upgrade | review | 9.26 | 1 |
| feature:wms-hygiene | workunit | Live-fire on chunk: Grafana provisioning and status colour maps (entity cost explorer, fd-data-quality) after the upgrade | build | 9.03 | 1 |
| feature:wms-hygiene | workunit | WP6 legacy-drain runbook rehearsal on chunk's clone (WP6-RUNBOOK.md §4): enumeration counts, the full close loop for populations A/B/C, journal rows, the dry-run listing shrink, and every runbook correction found | build | 9.01 | 1 |
| feature:wms-hygiene | workunit | Live-fire on chunk: engine + wms-mcp acceptance criteria (WP7 AC4, readiness hint, terminal-Outcome guard, WP9 AC4/AC11, WP2, WP10 MCP paths) | build | 7.07 | 1 |
| feature:wms-hygiene | workunit | Upgrade chunk in place from 6436eef to wt/wms-hygiene head 236ea6a with the recorded installrunner.sh invocation, verify, and release the re-run agents | build | 6.59 | 1 |
| feature:wms-hygiene | workunit | Live-fire on chunk: CLI acceptance criteria (WP9 AC5/AC6/AC8, wms list, WP10 CLI journal rows for wms close and wms gc) | build | 6.49 | 1 |
| feature:wms-hygiene | workunit | Add mcp-scraper timer to clone_install.go maskDisposableTimers (permanent clone masking, completing §12c) | build | 6.03 | 1 |
| feature:wms-hygiene | workunit | Scout: enumerate status/resolution consumers outside the WMS core (WP9 blast radius), wms gc and timers, WP4 feasibility | build | 5.91 | 1 |
| feature:wms-hygiene | workunit | Verify the chunk confirmation pass at 236ea6a (VERIFY.md §M commands, ledger check on the reopened-then-abandoned fixture, spot-check of the three re-run deliverables) | review | 5.72 | 1 |
| feature:wms-hygiene | workunit | Scout: re-enumerate the skill/doc corpus sites for WP1, WP1b, WP7 doc seams, WP8 and WP9 doc impact | test | 5.28 | 1 |
| feature:wms-hygiene | workunit | Live-fire on chunk: WP11 telemetry attribution (session_full in hook records, logrotate target, tailers survive rotation) | build | 4.16 | 1 |
| feature:wms-hygiene | workunit | Scout: verify WP7/WP9/WP10 engine, state-machine and journal claims against the worktree | test | 3.85 | 1 |
| feature:wms-hygiene | workunit | Consolidate the five live-fire result files into LIVEFIRE.md (AC matrix + findings register) for the operator's acceptance review | build | 3.75 | 1 |
| feature:wms-hygiene | workunit | Intake for the two remaining kit packages — WP4 sweep-report dashboard and WP11 §2 / WP12 mcp_tool_calls ledger: read the kit against the code at ea5280d and write dispatchable WU briefs (scope, files, ACs, gating, open design questions) | test | 3.57 | 1 |
| feature:wms-hygiene | workunit | Enable teamster-hookd.service at install/upgrade and on `teamster start` — no code path ever runs `systemctl enable` on hookd, so it does not survive a reboot (every other systemd-managed unit is enabled explicitly) | build | 3.33 | 1 |
| feature:wms-hygiene | workunit | Scout: verify WP11 telemetry-attribution claim and the four incidental defects in README §6c | build | 2.67 | 1 |
| feature:wms-hygiene | workunit | Chunk cycle 5: in-place upgrade to b9f2d6b — stop-race fix live proof, mcp-scraper install-time DDL proof, held proofs 5/WP6-step-3 unblocked | build | 1.75 | 1 |
| feature:wms-hygiene | outcome | WMS hygiene epic: GitHub #11 (entity lifecycle) and #17 (tagging docs) — kit, Train 1, live-fire, acceptance, Train 2 | build | 1.26 | 1 |
| feature:wms-hygiene | workunit | Review sweep Stage 2: a sweep-parked on_hold entity still inside AbandonAfter is invisible to the loop (SQL filters parked_at < threshold), so the design's within-window onhold-evaluated-skipped row is unreachable | review | 0.90 | 1 |
| feature:wms-hygiene | workunit | Comprehensive docs sweep: audit all product documentation for outdated and missing information from the v0.2.8 line | build | 0.60 | 1 |
| feature:wms-hygiene | workunit | Docs pass for the supervisor systemd units: §10 downgrade note, per-component supervision lever documentation | build | 0.30 | 1 |
| feature:wms-hygiene | workunit | WP12 Site B: prove on the test MySQL that a create call with a non-default initial status now journals the pending→<status> transition (wms.go:789-807 + the WorkUnit parallel), and correct WP12's stale AC7 text | build | 0.16 | 1 |

## 10. Whether every billed dollar is accounted for

Teamster's organizing promise is that every dollar lands somewhere visible.
This compares what was billed against what was attributed to some unit of work.
The result is one row, and on a healthy window the gap is zero or near it.

A zero residual means nothing was dropped. It does not mean everything was
measured — that is the next query, and it is the more important one.

```sql
-- static-window: full-history
SELECT ROUND(l.ledger_usd, 2)                                              AS billed_usd,
       ROUND(f.attributed_usd, 2)                                          AS attributed_usd,
       ROUND(l.ledger_usd - f.attributed_usd, 2)                           AS residual_usd,
       ROUND(100 * (l.ledger_usd - f.attributed_usd) / NULLIF(l.ledger_usd, 0), 2) AS residual_pct
FROM (SELECT SUM(cost_usd) AS ledger_usd
      FROM token_ledger
      WHERE timestamp >= (SELECT MIN(timestamp) FROM token_ledger)) l
CROSS JOIN
     (SELECT SUM(cost_usd) AS attributed_usd
      FROM cost_facts
      WHERE timestamp >= (SELECT MIN(timestamp) FROM token_ledger)) f
```

*(This fence declares `static-window: full-history`: its relative window has been widened to the anchor shown above so this page reflects full data history. The copy-paste version of this query in the live guide keeps the original recent window unchanged.)*

**Live result** (generated 2026-09-09 00:20:10 UTC):

| billed_usd | attributed_usd | residual_usd | residual_pct |
|---|---|---|---|
| 26942.89 | 26942.89 | 0.00 | 0.00 |

## 11. How much was measured and how much was inferred

Every attributed dollar carries the method that attributed it. Only
`temporal_join` is a direct measurement, where the message fell inside a
declared focus interval. Everything else is reconstruction:
`transcript_focus_recovery` reads the session transcript to work out what was
being worked on, `admin_warmup` books pre-focus orientation cost,
`gap_recovery` fills holes, and the `synthesized_*` methods invent a placeholder
when nothing else can be established.

Expect the recovered methods to dominate, typically by a large majority of
value. Every other figure in this document therefore rests substantially on
inference rather than on agents having declared their work correctly at the
time. That is not a flaw being concealed; it is the flaw being reported, which
is the difference between an attribution system you can argue with and one you
must trust blindly. Quote the method mix alongside any number taken from here.

The live method set is broader than the examples named above and grows over
time. This query is the authority on it, not any list written down.

```sql
-- static-window: full-history
SELECT a.method,
       ROUND(SUM(c.cost_usd), 2)                                  AS usd,
       ROUND(100 * SUM(c.cost_usd) / SUM(SUM(c.cost_usd)) OVER (), 1) AS pct,
       COUNT(DISTINCT c.message_id)                               AS messages
FROM cost_facts c
JOIN usage_attribution a
  ON  a.message_id  = c.message_id
  AND a.entity_type = c.entity_type
  AND a.entity_id   = c.entity_id
WHERE c.timestamp >= (SELECT MIN(timestamp) FROM token_ledger)
GROUP BY a.method
ORDER BY usd DESC
LIMIT 20
```

*(This fence declares `static-window: full-history`: its relative window has been widened to the anchor shown above so this page reflects full data history. The copy-paste version of this query in the live guide keeps the original recent window unchanged.)*

**Live result** (generated 2026-09-09 00:20:10 UTC):

| method | usd | pct | messages |
|---|---|---|---|
| transcript_focus_recovery | 14278.33 | 53.0 | 72348 |
| temporal_join | 6196.88 | 23.0 | 48527 |
| gap_recovery | 1858.96 | 6.9 | 14517 |
| synthesized_outcome | 1771.85 | 6.6 | 19232 |
| temporal_join_lead_fallback | 1671.98 | 6.2 | 10956 |
| temporal_join_lead_session_fallback | 644.17 | 2.4 | 2626 |
| admin_warmup | 281.76 | 1.0 | 2920 |
| sweep_skipped | 237.93 | 0.9 | 1181 |
| synthesized_remote_floor | 0.92 | 0.0 | 56 |
| brief_directive_recovery | 0.11 | 0.0 | 10 |

## 12. Which tag dimensions are worth slicing by

Which tag keys exist and how much spend each one can account for. A key
whose touched total approaches the window total gives near-complete coverage
and is safe to slice by; a key well below it describes only part of the data.

The column does not sum to the window total — each key sees the same dollars
from its own angle, so an entity carrying five keys contributes to five rows.
Roughly two dozen keys are live, including provenance keys recorded
automatically rather than declared.

```sql
-- static-window: full-history
WITH win AS (
  SELECT entity_type, entity_id, cost_usd
  FROM cost_facts
  WHERE timestamp >= (SELECT MIN(timestamp) FROM token_ledger)
)
SELECT t.tag_key,
       COUNT(DISTINCT t.tag_value) AS distinct_values,
       ROUND(SUM(w.cost_usd), 2)   AS usd_touched
FROM win w
JOIN entity_tags_resolved r
  ON r.entity_type = w.entity_type AND r.entity_id = w.entity_id
JOIN tags t ON t.id = r.tag_id
GROUP BY t.tag_key
ORDER BY usd_touched DESC
LIMIT 50
```

*(This fence declares `static-window: full-history`: its relative window has been widened to the anchor shown above so this page reflects full data history. The copy-paste version of this query in the live guide keeps the original recent window unchanged.)*

**Live result** (generated 2026-09-09 00:20:10 UTC):

| tag_key | distinct_values | usd_touched |
|---|---|---|
| phase | 10 | 27641.38 |
| work-type | 12 | 26650.35 |
| user | 1 | 26578.25 |
| product | 16 | 26562.32 |
| team | 131 | 24441.88 |
| priority | 4 | 22790.11 |
| component | 77 | 22413.91 |
| git.branch | 26 | 15498.70 |
| runtime | 1 | 14203.39 |
| feature | 81 | 14127.18 |
| github.owner | 3 | 11084.03 |
| github.issue | 10 | 8431.78 |
| resolution | 4 | 7441.00 |
| git.repo | 3 | 5832.91 |
| github.repo | 3 | 4425.53 |
| project | 2 | 2983.62 |
| research | 34 | 2983.50 |
| bug | 72 | 2490.95 |
| source | 1 | 1891.68 |
| docs | 5 | 970.50 |
| refactor | 4 | 802.83 |
| investigation | 19 | 691.30 |
| admin | 6 | 311.49 |
| rework | 3 | 137.69 |
| infra | 4 | 127.07 |
| test | 4 | 20.31 |
| polish | 1 | 14.74 |

## 13. How many separate efforts each kind of work covers

Each work-scope key with the number of distinct efforts under it and what
they cost between them. Dividing one by the other gives an average cost per
effort of that kind, which is often more revealing than either figure alone —
it distinguishes a work type made of a few large pushes from one made of many
small ones.

```sql
-- static-window: full-history
WITH win AS (
  SELECT entity_type, entity_id, cost_usd
  FROM cost_facts
  WHERE timestamp >= (SELECT MIN(timestamp) FROM token_ledger)
)
SELECT t.tag_key                   AS scope_key,
       COUNT(DISTINCT t.tag_value) AS distinct_efforts,
       ROUND(SUM(w.cost_usd), 2)   AS usd
FROM win w
JOIN entity_tags_resolved r
  ON r.entity_type = w.entity_type AND r.entity_id = w.entity_id
JOIN tags t ON t.id = r.tag_id
WHERE t.tag_key IN ('feature','bug','refactor','infra','research','docs','test','admin','rework')
GROUP BY t.tag_key
ORDER BY usd DESC
LIMIT 20
```

*(This fence declares `static-window: full-history`: its relative window has been widened to the anchor shown above so this page reflects full data history. The copy-paste version of this query in the live guide keeps the original recent window unchanged.)*

**Live result** (generated 2026-09-09 00:20:10 UTC):

| scope_key | distinct_efforts | usd |
|---|---|---|
| feature | 81 | 14127.18 |
| research | 34 | 2983.50 |
| bug | 72 | 2490.95 |
| docs | 5 | 970.50 |
| refactor | 4 | 802.83 |
| admin | 6 | 311.49 |
| rework | 3 | 137.69 |
| infra | 4 | 127.07 |
| test | 4 | 20.31 |