flagon-io/g1t

Pick any line to see why it is the way it is: the commit, the pull request and issue it came from, and what the agent was thinking.

Security tells people the way they can live with. Each scan publishes one summary event per alert type (secret_scanning_alert.summary, code_scanning_alert.summary, vulnerability_alert.summary: what it opened, by severity, what it fixed, what is open now, the worst new alert and the newest one's title, with the owners and security managers to tell) beside the per-alert events webhooks keep, so the inbox holds one thread per repository and alert type that the next scan brings up to date instead of one item per finding, and the ids are capped at 200 while the counts are not. Critical and high alerts and a refused push reach the inbox at once (and toast like a mention, as the new security notification kind); medium and low wait for each person's security digest, one inbox item and email per workspace, daily or weekly as they choose in their notification settings, at once, or never; a scan that opened nothing refreshes the thread quietly ("2 of 3 fixed") and marks it done when nothing is left open; and security alerts are emailed by default. A repository can turn alerts for secrets found in its history off while push protection stays on. Reporting arrives: security advisories (G1TSA ids, drafts published and withdrawn by Admins and security managers, visible to anyone who can see the repository once published) and private vulnerability reporting (a repository setting; anyone who can see it may report, signed out with an email on a public one, five a day each, and the owners and security managers are told at once), each with its RPC methods, REST routes under /repos/{owner}/{name}/security/advisories and /security/reports, MCP actions, scopes and reference examples.yesterday		1	-- Security alerts the way people can live with (src/inbox.rs, src/security_digest.rs):
		2	-- what each person chose about them, and what waits for their next digest.
		3
		4	-- Whether critical and high alerts on repositories they watch for security
		5	-- reach them at once (1, the default when null), and when the rest do:
		6	-- daily (the default when null), weekly, at_once or off.
		7	ALTER TABLE inbox_settings ADD COLUMN security_alerts INTEGER;
		8	ALTER TABLE inbox_settings ADD COLUMN security_digest TEXT;
		9
		10	-- One row per person per scan summary that waits for their digest: what
		11	-- the scan opened, by severity (JSON SeverityCounts), its headline and
		12	-- where the alerts are. The digest reads a person's rows, writes one inbox
		13	-- item per workspace, emails it, and deletes them.
		14	CREATE TABLE inbox_security_digest (
		15	id TEXT PRIMARY KEY,
		16	username TEXT NOT NULL,
		17	workspace TEXT NOT NULL,
		18	repo_id TEXT NOT NULL,
		19	repo TEXT NOT NULL,
		20	-- secret_scanning | code_scanning | vulnerability
		21	alert_type TEXT NOT NULL,
		22	event_id TEXT NOT NULL,
		23	opened INTEGER NOT NULL,
		24	counts TEXT NOT NULL,
		25	worst TEXT,
		26	title TEXT NOT NULL,
		27	link TEXT NOT NULL,
		28	created_at TEXT NOT NULL,
		29	UNIQUE (event_id, username)
		30	);
		31	CREATE INDEX inbox_security_digest_user ON inbox_security_digest (username, created_at);