Rule IDs are sha256(name+nsql)[..8] (parser.rs:613-619) and CreateRule persists via INSERT OR REPLACE (db.rs:1533-1548) with no existence check — two rules with the same name+NSQL text silently overwrite each other (a user creating a second identical-looking rule destroys the first). Goal: generate a real unique id (or check existence and reject/î distinguish on CreateRule) so creating a rule can never silently clobber an existing one. Test the collision scenario.
Source: full-tree audit 2026-07-30 (scratchpad/audit/AUDIT-SUMMARY.md). Follow docs/STORY-WORKFLOW.md: engine+proto(if surface)+CLI+offline E2E, mock-only tests, no fabricated data, comment convention, PR to dev, PO reviews before close.
Rule IDs are `sha256(name+nsql)[..8]` (parser.rs:613-619) and CreateRule persists via `INSERT OR REPLACE` (db.rs:1533-1548) with no existence check — two rules with the same name+NSQL text silently overwrite each other (a user creating a second identical-looking rule destroys the first). Goal: generate a real unique id (or check existence and reject/î distinguish on CreateRule) so creating a rule can never silently clobber an existing one. Test the collision scenario.
Source: full-tree audit 2026-07-30 (scratchpad/audit/AUDIT-SUMMARY.md). Follow docs/STORY-WORKFLOW.md: engine+proto(if surface)+CLI+offline E2E, mock-only tests, no fabricated data, comment convention, PR to dev, PO reviews before close.
Delivered via PR #267 (squash-merged to dev). Filter rule ids are now a 16-byte CSPRNG-random hex value (reusing the existing aes-gcm OsRng, no new dep) instead of sha256(name+nsql), so CreateRule can never silently overwrite a different rule that happens to share name+NSQL. INSERT OR REPLACE is harmless with unique ids; UpdateRule/list still preserve the persisted id. Test proves two identical-name+nsql rules coexist as distinct rules.
Delivered via PR #267 (squash-merged to dev). Filter rule ids are now a 16-byte CSPRNG-random hex value (reusing the existing aes-gcm OsRng, no new dep) instead of sha256(name+nsql), so CreateRule can never silently overwrite a different rule that happens to share name+NSQL. INSERT OR REPLACE is harmless with unique ids; UpdateRule/list still preserve the persisted id. Test proves two identical-name+nsql rules coexist as distinct rules.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Rule IDs are
sha256(name+nsql)[..8](parser.rs:613-619) and CreateRule persists viaINSERT OR REPLACE(db.rs:1533-1548) with no existence check — two rules with the same name+NSQL text silently overwrite each other (a user creating a second identical-looking rule destroys the first). Goal: generate a real unique id (or check existence and reject/î distinguish on CreateRule) so creating a rule can never silently clobber an existing one. Test the collision scenario.Source: full-tree audit 2026-07-30 (scratchpad/audit/AUDIT-SUMMARY.md). Follow docs/STORY-WORKFLOW.md: engine+proto(if surface)+CLI+offline E2E, mock-only tests, no fabricated data, comment convention, PR to dev, PO reviews before close.
Delivered via PR #267 (squash-merged to dev). Filter rule ids are now a 16-byte CSPRNG-random hex value (reusing the existing aes-gcm OsRng, no new dep) instead of sha256(name+nsql), so CreateRule can never silently overwrite a different rule that happens to share name+NSQL. INSERT OR REPLACE is harmless with unique ids; UpdateRule/list still preserve the persisted id. Test proves two identical-name+nsql rules coexist as distinct rules.