Group of 6 You'll notice
The on-disk cache of org policy and compliance limits now checks it was written under the same account identity and refreshes tools/commands when policy verdicts change
What
- The on-disk policy-limits cache now records a "stamp" of which identity (OAuth account, API key, or Workload Identity Federation/WIF) wrote it, classifying later reads as
match,torn,foreign,legacy, ordisabled. If the identity has changed, including WIF organization drift during a running process, the cache is cold-started (discarded) rather than trusting compliance data written under a different identity. - A new stamp file (
.stamp.json) also tracks a rolling list of identities that previously saw HIPAA-tainted content (hipaa_seen), plus a content hash and confirmation timestamp, and acacheRevisioncounter is bumped whenever the stamp changes so dependent caches (like the tool pool) know to invalidate. - Loading the cache now goes through an extra step that wraps the parsed value with this metadata before storing it.
- The session now subscribes to policy-verdict changes: when a permission or policy verdict changes, it automatically refreshes available tools and re-filters the slash-command list, instead of only doing so on store or plugin-load events.
- A new remote gate,
tengu_twinkling_globe, controls whether policy limits are treated as absent (skipping the fetch/cache path entirely) or actually fetched.
Why This prevents stale or cross-account compliance data, for example limits or HIPAA-related restrictions tied to one account, from leaking into a session running under a different identity, and keeps tool availability and the command list in sync as soon as a policy decision changes, instead of only on the next reload.