A reusable design question concerns an agent plugin that caches task context before applying a system-message transform while multiple root and child sessions share one process. The key unknowns are how cache ownership and lifecycle should be modeled to prevent cross-session disclosure, and how memory limits and eviction should be enforced. This is a reasoning discussion only; no repository inspection or tests have been performed.

Reasoning result: use an immutable, fully qualified cache key containing plugin instance, authorization lineage, root session identifier, explicit child session identifier, session epoch, authorization generation, content revision, and policy or capability scope wherever reuse could cross a boundary. Keep root and child entries separate. A child may receive only a bounded immutable snapshot explicitly selected by the parent; never share mutable buffers, request objects, callbacks, or full histories. Treat authorization generation as live state and compare it at lookup, transform, injection, refresh, and network admission; missing or mismatched generations fail closed. Advance the generation atomically on replacement or revocation, then invalidate entries and cancel associated work. Bind each request to its session identity and re-check identity immediately before injection so out-of-order asynchronous completion cannot write into another session. Clear entries on normal completion, cancellation, logout, authorization change, and plugin disposal. Do not use process-global current-session variables or ambient mutable context. For memory bounds, enforce both per-session and process-wide budgets, count actual serialized bytes plus metadata, cap entry count, context size, history depth, and concurrent child sessions, and reject or truncate new writes when limits are reached. Prefer immutable bounded snapshots and deduplicate only within the same security domain. Use TTL and idle expiry as secondary controls, plus weighted LRU or clock eviction among entries that are not pinned by active work; active entries need a deadline and may be forcibly canceled when over budget. Zeroize or release sensitive buffers on eviction where the runtime permits, and avoid retaining large error objects or closures. Instrument counts, bytes, evictions, rejected writes, generation mismatches, and active pins without logging context contents. Tests should include concurrent roots, parent-child isolation, delayed transforms, cancellation, revocation during queued work, eviction under pressure, and disposal. This is design reasoning only: no repository inspection and no tests were executed.

Required extension: authorization generation is part of the cache identity and must be treated as an atomic capability epoch, not merely metadata. Maintain a per-authorization-lineage generation counter or opaque generation identifier. Every cached entry records the generation captured when it was created, and every transform or request carries that same generation. On revoke or replacement, atomically advance the generation before publishing the new authorization state, mark all older entries stale, cancel queued work tied to older generations, and prevent new lookups from returning them. A stale entry must never be used to construct a system-message transform, refresh a context, or authorize network activity. Network admission must re-read the current generation and authorization state immediately before dispatch, compare them with the request snapshot, and fail closed on mismatch, missing state, or revocation. If the network operation can outlive admission, bind cancellation and response handling to the generation as well; discard late results from an obsolete generation. Do not rely on deletion alone, because an in-flight reference can survive deletion. Use immutable snapshots, generation checks at every security boundary, and atomic publication ordering: invalidate old generation, cancel or mark old work, then install the replacement. Tests should reason through revoke during cache lookup, transform, queue delay, retry, and response completion, plus replacement followed by a late old-generation callback. This remains standalone design reasoning only; no repository inspection or tests were executed.