T27F Evolution Runtime: prototype bounded self-adaptation, hot-swap, rollback and live visualization #1655

Goal

Define and prove a minimal self-adapting runtime loop for Trinity/T27F: observe live state, propose a bounded change to one component, build/validate it in isolation, apply it without a full application restart when technically supported, and visualize the transition. This is an experiment and architecture decision, not a claim of self-modifying AI already working.

Boundary

• Parent: T27F architecture epic EPIC: T27F — Native generative UI and visual application engine #1648 and MVP MVP: benchmark generative-UI competitors and prototype T27F research workspace #1652. Keep task-intake hardening P0: Make Queen/Bee task formatting valid by construction and repair skipped issues #1654 as a separate prerequisite/workstream; do not fold unrelated queue repairs into the runtime prototype.
• Scope: first audit existing Trinity/T27 runtime and build/release capabilities; then choose one reversible, low-risk component and implement a measured vertical slice.
• Allowed: read-only audit, small isolated prototype, tests, profiling, event/state visualization, feature-flagged hot swap where the current runtime supports it, and rollback instrumentation.
• Not allowed: unrestricted self-modifying production code, arbitrary generated code in the trusted UI path, automatic production rollout without tests/permission, claims of millisecond end-to-end update without measurements, or claims of consciousness.
• Separation of concerns: distinguish state/config update, plugin/component replacement, source-code change, recompilation, model-weight training, and UI re-render. They are not interchangeable and must be measured independently.
• Output: exact repository paths/symbols, architecture diagram, runnable reproduction, commands, environment, raw timings, test outcomes and limitations. Mark each feature implemented/partial/proposed/unknown.
• Completion: complete only after the audit, one working bounded adaptation loop, regression/failure tests, rollback demonstration, and before/after latency measurements are linked. Issue creation or a dispatch receipt alone is not completion.

Work plan

1. Audit current capabilities. Inspect the real runtime, plugin/component model, T27 build/release pipeline, state persistence, UI renderer, test harness and Queen/bee task execution. Identify what “release in milliseconds” refers to and measure each stage; do not assume build, validation, activation and rendering all fit the same latency.
2. Define the smallest target. Choose one harmless component with a typed interface and stable ID. Specify current version, candidate version, input/output contract, allowed change surface and rollback behavior.
3. Create an isolated evolution loop. Observe event/state → propose patch/config/profile → schema and permission checks → build/test in isolation → compare acceptance tests → stage candidate → activate behind a feature flag or atomic swap if supported → health-check → retain previous version for rollback.
4. Connect T27F visualization. Show active/candidate versions, lifecycle events, test results, activation status, error, rollback, and timing per stage. A presentation-profile change must not mutate authoritative world state.
5. Test failure paths. Invalid patch, schema mismatch, failed build, failed test, timeout, crash after activation, stale state, permission denied, interrupted update, and rollback failure. Unsafe or failed candidates must not replace the healthy version.
6. Measure adaptation vs training. Demonstrate the bounded runtime/component adaptation first. Treat learned parameter updates and neural-network weight training as separate experiments with their own validation and persistence.
7. Run the end-to-end demonstration. Change one component while the app is running, validate it, apply it without a full restart if supported, show the new behavior in T27F, and revert to the previous version. Publish median/p95 timings and state whether each step is synchronous, asynchronous or not yet supported.

Acceptance criteria

• Source-backed capability audit with exact paths/symbols and implementation status.
• Explicit state machine and typed contract for candidate/active/rollback versions.
• One runnable, reversible adaptation demo.
• Tests prove failed candidates never become active and healthy prior versions can be restored.
• T27F displays actual runtime events and measured latency, not simulated status.
• Separate timings for proposal, build, validation, activation, health-check and UI update; no unsupported millisecond claim.
• Report states clearly what this does and does not demonstrate about learning; no inference of consciousness.
• Link all code, tests, benchmark output and remaining blockers.

Architecture hypothesis

Queen coordinates intent and delegated work; T27 provides the relevant build/validation or numeric capabilities where verified; a controlled runtime owns activation/rollback; T27F visualizes state/events. These responsibilities must be confirmed against the repositories before implementation.

Related work

• T27F architecture and shared world model: EPIC: T27F — Native generative UI and visual application engine #1648
• T27F UI research/prototype MVP: MVP: benchmark generative-UI competitors and prototype T27F research workspace #1652
• Queen/Bee task intake hardening: P0: Make Queen/Bee task formatting valid by construction and repair skipped issues #1654
• Queen/Bee runtime liveness: EPIC: Queen + Bee Runtime Performance — measure, eliminate stalls, reuse work, then accelerate the core #1645