dogfood-snapshot: active-day count includes demo/E2E fixture activity

[Chris0Jeky]

The active-day metric in scripts/dogfooding/dogfood-snapshot.py unions dates from AuditLogs, Cards, AutomationProposals, ChatMessages and LlmRequests without applying noise_board_ids(). So on a shared dev database, a day on which only E2E fixtures or seeded demo boards were touched counts as an active dogfooding day.

That matters because active days is the metric #1271 is scored on, and the rubric in docs/dogfooding/README.md keys its archive/revive bands to it.

Why it was not fixed inline

The join is not uniformly available. Cards reach a board through Columns, but AuditLogs, ChatMessages and LlmRequests are not board-scoped at all — there is no honest way to attribute a chat message or an LLM request to a demo board without inventing an attribution rule. Filtering only the tables that can be filtered would produce a number that is neither all-activity nor real-activity, which is worse than the current one because it would look precise.

Current mitigation

The tool already warns loudly when more than half the boards are fixtures, and both docs make a separate TASKDECK_DOGFOOD_DB the first structural step — which dissolves the problem rather than approximating around it. On a clean dogfooding database there is no fixture activity to exclude.

So this is a real defect only for the shared-dev-database case, which is explicitly the case the docs tell you not to measure.

Suggested fix, when it is worth doing

Either:

1. Attribute what can be attributed (Cards via Columns.BoardId, AutomationProposals.BoardId) and report two numbers — all activity and board-attributable-non-fixture activity — never a single blended one; or
2. Add a --exclude-fixtures flag that drops the non-attributable tables entirely and says so in the output, so the reader knows the count is a lower bound.

Option 2 is probably the honest one: a smaller number that is provably real beats a larger one that is partly fixture.

Provenance

Codex P1 on PR #1478. Fixed alongside it: the funnel now counts applies by AppliedAt (a status-based count understated it 17x), LlmRequests added as an activity source, the verdict scores the window rather than all time, and a degenerate DB no longer reports "not started".

[Chris0Jeky]

Folded in from PR #1478 round 3 (Codex P2): capture-inbox review days are also missed. CaptureService mutates an existing LlmRequest through UpdatePayload() / Cancel() without creating a counted record or audit entry, so a day spent only editing or ignoring captured suggestions does not register as an active day.

The fix is not simply adding LlmRequests.UpdatedAt. The same round showed why: adding AutomationProposals.UpdatedAt to catch review days also enrolled ProposalHousekeepingWorker, whose Expire() bumps that column every minute — manufacturing active days from an idle machine. Any UpdatedAt column needs a per-writer audit (which writers are human, which are the worker) before it can be trusted as a human-activity signal.

So this issue now covers two related activity-source questions:

1. fixture/demo activity is not excluded (original scope);
2. human mutations that reuse an existing row are not counted, and the obvious fix risks counting machine mutations instead.

Both push the count in opposite directions, which is worth solving together rather than one at a time.

[Chris0Jeky]

Third fold-in from PR #1478 (Codex round 4): a deferral-only day is invisible. Defer() calls only Touch() and DeferProposalAsync deliberately writes no audit or notification row, so UpdatedAt is the only signal — and that is exactly the column removed because ProposalHousekeepingWorker.Expire() bumps it every minute.

The two findings are in direct tension:

• include AutomationProposals.UpdatedAt → an idle machine with the API running manufactures active days;
• exclude it → genuine deferral days vanish from the count.

Neither is acceptable, and patching either direction in isolation just moves the error. The resolution is a per-writer audit of which UpdatedAt mutations are human-initiated, applied once across AutomationProposals and LlmRequests together.

That makes this issue's real scope: what counts as a human active day, and which columns can prove it. Three sub-questions now sit under it — fixture exclusion, row-reusing human mutations (capture edit/cancel), and machine-vs-human UpdatedAt. The current count is a documented lower bound, which is the safe direction for an acceptance test.

[Chris0Jeky]

Round-5 note (PR #1478): redact() produced two disclosure-shaped bugs in the same six-line function within one review cycle — first a missing path-component boundary (/home/alice-client/... → ~-client/...), then an unconditional case-fold (/home/Alice vs /home/alice on a case-sensitive filesystem). Both are fixed, but the pattern is the finding: a function whose whole job is not disclosing something should not be inline string surgery with no tests.

Worth folding into this issue's scope: extract redaction to a helper with a small table-driven test (inside home, sibling-prefixed, case variants, UNC/relative, home-is-root), since the output is explicitly advertised as safe to paste into public issues.

[Chris0Jeky]

Rounds 5–6 fold-in (PR #1478), and a scope statement.

Two more activity-source gaps: board-only days (Boards has its own CreatedAt/UpdatedAt, and board mutations continue after best-effort audit failures, so creating or updating an empty board can register as inactivity) and candidate ordering in find_db() (repo-relative entries win over application-managed ones, so a stale repo DB can be preferred over a current packaged one).

This issue now owns one coherent question rather than four loose ones:

What counts as a human active day, and which columns can prove it?

Sub-questions, all evidenced from PR #1478's six review rounds:

1. fixture/demo activity is not excluded from the day count;
2. human mutations that reuse an existing row (capture edit/cancel, deferral) are not counted;
3. UpdatedAt columns mix human and machine writers — adding AutomationProposals.UpdatedAt to fix (2) enrolled ProposalHousekeepingWorker and manufactured active days, so Boards.UpdatedAt and LlmRequests.UpdatedAt must not be added without the same audit;
4. there is no user-account filter, and a declared-but-unapplied one was removed rather than left implying coverage;
5. find_db() precedence between repo-local and application-managed databases;
6. redact() should be a tested helper — it produced two disclosure-shaped bugs in six lines.

The meta-point worth keeping: items (2) and (3) push the count in opposite directions, and every single-item patch during the review moved the error rather than removing it. This needs one design pass with a writer audit, not another round of increments.

[Chris0Jeky]

Coordinator disposition (2026-09-06, Codex-session PR carried under the standing D-12 route: fresh-context review, MEDIUM+ fixed in-PR, merged as a merge commit).

Two PRs: #2750 (Inventory human activity writers, merged d9645bf9a; review SHIP; LOWs: a few AutomationProposal.cs/Board.cs line anchors drifted, Expire() is also called from AutomationProposalService.cs:1352) and #2741 (Harden dogfooding diagnostic path redaction; review SHIP, MEDIUM-2 fixed in-PR: the No such database exit message now redacts the path too; merges when its hosted run is green). Remaining from #2741: MEDIUM — scripts/dogfooding/test_dogfood_snapshot.py is executed by no CI job (reusable-docs-governance.yml discovers only the agent_hooks and analysis suites), so a regression in redact stays green; wiring it is a control-plane change and is left for the CI lane. LOW — a POSIX filename containing a literal backslash renders as a directory boundary (pre-existing).

[Chris0Jeky]

PR #2741 merged as 4b6dd5d00 at head d952d8598 (hosted run green); the CI-wiring MEDIUM recorded above stays open.