Skip to content

Flag tasks with secret findings in Hub sync - #340

Merged
mando merged 2 commits into
mando-issue-335-secret-scan-versionfrom
mando/task-flags-to-hub
Aug 18, 2026
Merged

Flag tasks with secret findings in Hub sync#340
mando merged 2 commits into
mando-issue-335-secret-scan-versionfrom
mando/task-flags-to-hub

Conversation

@mando

@mando mando commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

Summary

  • derive a boolean task flag from local secret findings joined through task interactions
  • upload only the boolean, keeping finding details and transcript text local
  • document the sync boundary and add coverage for flagged and unflagged tasks

Verification

  • bun test
  • bun run typecheck

Closes the task flagging follow-up for the secret scanning work.

mando added a commit that referenced this pull request Aug 17, 2026
Review of #340 found the flag couldn't reach the Hub for the sessions it exists
to serve. computeSessionDigest watched none of what the scan drain writes, so a
back-catalogue session whose only change was "we just found a credential in it"
kept its old digest and sync skipped it. Worse, a re-index cascaded the findings
away and uploaded flagged:false, and the drain re-finding the same credential
changed nothing, so the flag un-set permanently. The digest now folds in which
tasks a session's findings flag, per-task so re-interpretation moving a finding
between tasks still re-syncs.

The flag ignores secret_scan_dismissed, alone among readers of that table. That
is intended, not an oversight, so it now says so where someone would go to
"fix" it: dismissal silences one user's banner, while the flag is the org's
record that a piece of work touched a credential, and a signal that depends on
who clicked Dismiss is not one an org can reason about. The digest ignores
dismissal for the same reason, so a dismissal causes no pointless re-upload.

Sync opens the store read-only and never migrates it, so the flag query threw
"no such table: resolved_secret_findings" on a pre-v24 store, printing a SQLite
error every watch interval instead of reaching the Hub's 422 and its re-index
guidance. Probe for the table, and report no flags when it's absent.

Four surfaces still promised findings never cross the wire (database-schema.md,
the findings DDL comment, the store contract, CLAUDE.md twice). They now say what
is actually true: no finding row is uploaded, one derived boolean is.
mando added 2 commits August 18, 2026 15:50
Review of #340 found the flag couldn't reach the Hub for the sessions it exists
to serve. computeSessionDigest watched none of what the scan drain writes, so a
back-catalogue session whose only change was "we just found a credential in it"
kept its old digest and sync skipped it. Worse, a re-index cascaded the findings
away and uploaded flagged:false, and the drain re-finding the same credential
changed nothing, so the flag un-set permanently. The digest now folds in which
tasks a session's findings flag, per-task so re-interpretation moving a finding
between tasks still re-syncs.

The flag ignores secret_scan_dismissed, alone among readers of that table. That
is intended, not an oversight, so it now says so where someone would go to
"fix" it: dismissal silences one user's banner, while the flag is the org's
record that a piece of work touched a credential, and a signal that depends on
who clicked Dismiss is not one an org can reason about. The digest ignores
dismissal for the same reason, so a dismissal causes no pointless re-upload.

Sync opens the store read-only and never migrates it, so the flag query threw
"no such table: resolved_secret_findings" on a pre-v24 store, printing a SQLite
error every watch interval instead of reaching the Hub's 422 and its re-index
guidance. Probe for the table, and report no flags when it's absent.

Four surfaces still promised findings never cross the wire (database-schema.md,
the findings DDL comment, the store contract, CLAUDE.md twice). They now say what
is actually true: no finding row is uploaded, one derived boolean is.
@mando
mando force-pushed the mando/task-flags-to-hub branch from 8ff24e9 to 2bbfbc6 Compare August 18, 2026 20:50
@mando
mando merged commit c3cff70 into main Aug 18, 2026
1 check passed
@mando
mando deleted the mando/task-flags-to-hub branch August 18, 2026 20:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant