[cyanask]

Updates the Company Guard package from 0.4.3 to 0.4.6, following the merged #903. The package tracks the validated public source while retaining the community package name and installation compatibility.

Changes:

• Add local custom-rule management with multiple aliases, duplicate/limit validation, concurrent-edit checks and warnings before discarding unsaved edits. Separate built-in recognition and custom rules into two subpages; custom rules open by default.
• Document recognition boundaries in the page. Keep entity association and financial amount masking outside this update.
• Add local rule-version and authorization-change summaries. Display up to 100 history summaries separately from the global 25-request receipt window.
• Mask text in tool-schema defaults, constants and examples; recover valid stages from damaged receipts and surface read-health warnings.
• Simplify receipt summaries, improve agent identity and history controls, and verify the committed middleware against its source during tests.

Validation:

• Public package: 31 Node tests and 31 Bun tests passed.
• Community package: 33 Node tests and 33 Bun tests passed, including pinned and unpinned community installation names.
• Upstream checker tests: 17 passed; registry validation passed. The repository checker skips middleware execution, which is covered by the package tests above.
• Both package dry-runs and 23 JavaScript syntax checks per candidate passed. Runtime files match the installed, accepted version, apart from the community installation-name adapter.
• Installed macOS Magpie verified both rule subpages, default selection, keyboard switching, history loading, and both unsaved-change choices. Existing rules, keys, grants and explicit ports were preserved; Magpie and the gateway were not restarted for this publication.

Only source, generic documentation, licenses and existing tests are included. No local keys, signed grants, plugin configuration, company lists, business data or acceptance screenshots are included. Default port 3469 and macOS support remain unchanged. Detection remains rule-based and text-only; bypassing Magpie, images and binary files remain outside its scope.

Review follow-up: authorization capacity

• Restore pruning of ordinary revoked entries when planning the next authorization. Keep revocation markers while independent legacy grants could otherwise reactivate the session, and keep authorization event history separately.
• Use one shared 100-entry limit in API validation, planning and request-time lookup. Keep the serialized-registry length limit (3 × 1024 × 1024 UTF-16 code units), the 4 MiB request-body limit and the 32-name approval limit. Never evict active authorizations to make room. Archiving a Codex chat does not revoke its grant.
• Add a regression in the existing test file that approves/revokes 106 distinct sessions and then approves another. The same planner is used by /authorization/plan. Also cover recovery from 64 existing revoked records, actual request handling at a full 100-entry table, refusal to evict active grants, legacy-marker retention and the size limit.
• Re-ran the public package (31 Node / 31 Bun tests) and community package (33 Node / 33 Bun tests), build-consistency checks, packaging and registry validation. No latency benchmark was run, so 100 is a bounded capacity choice rather than a measured performance threshold.

[yetone]

Thanks — I read the whole diff and ran it on a macOS box at d84c3bd: npm run check:dist matches the source and node --test passes 32/32. The rules page, the schema masking (enum/const/default/examples and the properties/$defs walk), the rule history and the receipt recovery all look right to me.

One change I can't merge as it is, in receipt-page.mjs /authorization/plan:

-    const legacySessions=new Set(legacy.map(r=>r.session));
-    const entry=…,entries=body.entries.filter(e=>e.session!==record.session&&(readAuthorization(e,options.authKey).state==="active"||legacySessions.has(e.session))).concat(entry);
+    const entry=…,entries=body.entries.filter(e=>e.session!==record.session).concat(entry);

Before, a revoked record was dropped from sessionAuthorizations (unless a legacy grant needed it to stay revoked). Now every revoked record is kept for good, and nothing else prunes them. Both checks count them: body.entries.length>64 → invalid_registry, and entries.length>64 → authorization_too_large. So once a user has approved and later revoked 64 different sessions, every new approval on that machine fails, and the page offers no way out short of editing the options by hand.

The PR body doesn't mention this change and no test covers it. If keeping revoked records is on purpose (for example, so a revocation still reads as session_revoked rather than "not managed"), please either keep only the legacy-backed ones as before, or cap/expire the revoked ones (oldest first) so they can't fill the 64 slots. Please add a test that approves and revokes more than 64 sessions and then approves one more.

Everything else is fine with me, so I'll merge once that's sorted.

[yetone]

Merged, thanks @cyanask. Bun and node --test each gave 33 pass, 0 fail, and check.mjs was ok. I compared the dist changes with the src changes line by line. I didn't run build.mjs --check because esbuild isn't on the test box. 0.4.6 goes out with the publish run.