2dcd5cb6a8
The runtime process table is read through a module-level executor cache (1s TTL) but its consumers rebuild on a 2s snapshot-cache cadence and fire constantly during a launch (every team file change invalidates a per-team snapshot). A 1s table TTL is shorter than the 2s read cadence, so 'ps -ax' was re-spawned on essentially every consumer rebuild for no freshness benefit -- a top main-thread cost in the warm launch profile (~5-8%). Raise the table TTL to 2s to match the consumer window so the spawn coalesces to at most once per consumer cycle. Safe: liveness is identity-matched (team+agent+command), not bare-PID, and OpenCode host cleanup re-validates each PID against live state before killing, so a ~2s-stale table cannot cause a wrong liveness verdict or an unsafe kill -- it only widens an already-tolerated display-staleness window by ~1s. No test asserts the TTL value. |
||
|---|---|---|
| .. | ||
| agent-attachments | ||
| agent-graph | ||
| anthropic-runtime-profile | ||
| codex-account | ||
| codex-model-catalog | ||
| codex-runtime-installer | ||
| codex-runtime-profile | ||
| localization | ||
| member-log-stream | ||
| member-work-sync | ||
| recent-projects | ||
| running-teams | ||
| runtime-provider-management | ||
| team-runtime-lanes | ||
| tmux-installer | ||
| workspace-trust | ||
| CLAUDE.md | ||
| README.md | ||
Features
This directory contains the canonical home for medium and large feature slices.
Before creating or refactoring a feature, read:
Reference examples:
recent-projects- full cross-process feature with contracts, core, main, preload, renderer, and focused testsagent-graph- thin feature withcore/domainand renderer integration onlycodex-model-catalogandteam-runtime-lanes- process-limited features that omit renderer or preload layers when they do not own those boundaries
Use src/features/<feature-name>/ by default when the work introduces:
- a new use case or business policy
- transport wiring
- more than one process boundary
- more than one adapter or provider
Feature-local docs should answer navigation questions:
- which shape the feature uses
- which entrypoints are public
- where new adapters, rules, bridges, or renderer surfaces belong
- what tests protect the behavior
- which local files are the best examples for future changes
Do not duplicate architecture rules in feature folders. Keep the standard centralized in ../../docs/FEATURE_ARCHITECTURE_STANDARD.md.
Rule of thumb:
recent-projectsis the full slice example with process-aware outer layersagent-graphis the thin slice example built aroundcore/plusrenderer/