Skip to content

Repair MCP retention diagnostic accounting and natural/GC evidence - #654

Merged
trissim merged 8 commits into
mainfrom
docs/setup-acceptance-followup-131-132-169-20261004
Oct 5, 2026
Merged

trissim merged 8 commits into
mainfrom
docs/setup-acceptance-followup-131-132-169-20261004

Conversation

@trissim

@trissim trissim commented Oct 4, 2026 •

Copy link
Copy Markdown
Collaborator

Working diagnostic repair for #131

The existing diagnostic now observes host availability, swap and full PSI without
an invented 8-GiB host floor or 2-GiB MCP veto. Finite caller-selected rounds and
cadence replace the 180-second overall quota. Per-call deadlines, strict typed
decoding, exact child import identity and the read-only sequence boundary remain.

Natural pre-GC end-of-round samples determine retention slopes. Optional final
--gc-at-end records a separate signed sensitivity delta through the SAME
Annotated RetentionMetric declarations. It does not manufacture flat natural
retention or collect a scientist's process.

Owners: ProcessMemoryReceipt captures Linux accounting once; RetentionMetric
owns projections/calculations; MemoryDiagnosticReport owns cadence/evidence;
MemoryDiagnosticMcpClient retains typed requests/results; DiagnosticServerSpec
inherits the ordinary child/import lifecycle. No new launcher, scope store,
runtime consolidation patch, forced restart or scientific replay.

Qualified production pin283c2378a; normally integrated current main4d7f18858
does not change these diagnostic modules. Existing-family AST covers710 modules,
zero parse omissions; ownership guard PASS and13 diagnostic controls PASS.
Ordinary receiving02 qualifies920 RECORD entries/817 source/792 Python/13 skill
files. The real installed MCP check completed30 samples/three natural rounds
plus one final GC, original handle94550 terminal0 in18.95s. MCP1737168 is gone.
Natural RSS396696→397128→397444KiB, slope374KiB/round; separate final GC delta0.
Host availability/pressure remained observational, including full PSI avg10=1.17.
No leak verdict or biological claim follows from these short measurements.

Preserved negatives: repository-plugin import failed controls01 before collection;
live01 failed before sampling because the old health reader decoded an already
typed result as a mapping. Both original owned processes exited before source
repair/new live02. The current consumer uses the existing nominal result API.

Complete actual source/installed receiving receipt
records source identity, commands, failures, metrics and closure. Original private
evidence root: /home/ts/wt/openhcs-issue-batch-20260929/engineering-mcp-retention-131-20261005.
The original UNCERTAIN revision remains untouched; no synthetic source submitted.
New registration requires an actually owned endpoint/prepared native catalog,
not a fake port or relaxed read-only boundary. That longer #131 acceptance remains
Planck-owned with lane custody through Dewey.

This PR retains the follow-up plan for #132/#169, but does NOT close them or #131
on the strength of a short diagnostic. The original long mixed-MCP retention
journey and causal attribution remain distinct acceptance boundaries. A stable
3.78-GB process sample is not a leak diagnosis. Useful diagnostic repair may ship
without pretending the longer issue is resolved. Hosted CI is deferred by user
instruction; actual local/installed diagnostic evidence is now recorded.

@trissim

trissim commented Oct 5, 2026

Copy link
Copy Markdown
Collaborator Author

Cross-machine production-freeze handoff (5 Oct)
Current head 7e78266 changes only plans/setup_acceptance_followup_131_132_169.md. It is an acceptance-follow-up document, not a pending production code change, so it does not hold the benchmark freeze. Keep MCP installation, CZI input and desktop receiving issue closure tied to the corresponding actual accepted user paths rather than treating a plan merge as completion.

@trissim

trissim commented Oct 5, 2026

Copy link
Copy Markdown
Collaborator Author

Current determining status: head7e782663 changes only plans/setup_acceptance_followup_131_132_169.md. It is a follow-up acceptance plan, not unmerged production runtime code and not a benchmark-freeze blocker.

Merged implementation is distinct from the remaining exact user paths: #131's original long mixed-revision MCP interval, #132's real selected-container Java/CZI receiving, and #169's continuous installed desktop capture/restart/history restoration. Later short headless/installed or scientific receiving does not automatically prove those specific journeys. They remain named open acceptance boundaries; no obsolete Root #394 release hold is needed.

Keeping this plan draft open rather than claiming those issues completed or merging a document as runtime acceptance. No build, runtime replay or new verification gate was introduced by this reconciliation.

@trissim

trissim commented Oct 5, 2026

Copy link
Copy Markdown
Collaborator Author

Planck resumes the existing #131 MCP acceptance/source follow-through; no parallel runtime implementation or scientific-process adoption. Current determining source openhcs/mcp/memory_diagnostic.py still has require_ram_headroom() hard8GiB refusal before every call, sample() hard2GiB RSS refusal, a180s overall wait and2..10 rounds; repeated slopes use end samples after forcedGC. Those restrictions cannot receive the new issue131 one-point MCP RSS3,791,212KiB/privateDirty3,557,872KiB observation or establish38-minute natural retention. This is an acceptance-tool limitation, NOT a leak diagnosis. Current standing policy prohibits invented resource caps; the plan language to preserve historical caps is superseded. Existing owners remain ProcessMemoryReceipt/RetentionMetric/MemoryDiagnosticReport, MemoryDiagnosticMcpClient and DiagnosticServerSpec; the read-only sequence boundary remains strict, separately admitted synthetic revision A→B uses ordinary typed public tools. No source patch, new MCP/native/viewer, forcedGC on science, restart or uncertain revision replay was performed. Next determining work is a coherent update of this existing diagnostic to measured telemetry plus explicit duration/cadence and natural-versus-GC evidence, then one separately recorded admitted engineering run. #132/#169 unrelated acceptance stays open; merged575 consolidation is not re-proved or blamed for this MCP sample.

@trissim trissim changed the title Complete remaining MCP, CZI and desktop receiving acceptance Repair MCP retention diagnostic accounting and natural/GC evidence Oct 5, 2026
@trissim

trissim commented Oct 5, 2026

Copy link
Copy Markdown
Collaborator Author

Working source283c2378a published. Existing ownership guard passes; AST related-family710 modules/zero parse omissions and typed import/consumer closure recorded. Ordinary receiving01 wheel/920 RECORD817source792Python/13skills passed;13 diagnostic controls passed in6.76s. Original live01 reached the real MCP but failed before sampling: the stale diagnostic health consumer decoded an already-nominal McpServerHealthResult as a mapping. Client1720561/MCP1720693 both exited; original failure JSON/log/time retained. Source now consumes McpDevToolResult.decoded_payload_as rather than inventing another codec. New receiving02 builds that explicit corrected source; no shared installation/science/UNCERTAIN revision replay. This is diagnostic repair, not proof of a leak or closure of the long mixed-revision #131 scope. Canonical receipt follows after the same-owner installed check.

@trissim
trissim marked this pull request as ready for review October 5, 2026 21:43
Copilot AI balanced review requested due to automatic review settings October 5, 2026 21:43

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@trissim

trissim commented Oct 5, 2026

Copy link
Copy Markdown
Collaborator Author

Ready for parent review at exact head d0e0475. Normal integration includes current main4d7f18858; final determining main...HEAD diff is ONLY4 files: diagnostic owner, its unit family, retained acceptance plan and committed ACTUAL-RECEIVING.rst. No foreign gitlink/revert/churn. Diagnostic+launch production bytes remain identical to installed qualified283c2378a. Local determining diff: /home/ts/wt/openhcs-issue-batch-20260929/engineering-mcp-retention-131-20261005/FINAL-DETERMINING.diff . Committed receipt: docs/validation/mcp-natural-retention-131-20261005/ACTUAL-RECEIVING.rst (isolated WT /home/ts/wt/openhcs-context-bounding-20260929). Actual live02 terminal0/30 samples/one final GC; original MCP1737168 is gone. All failures preserved. #131/#132/#169 are NOT auto-closing; no leak/long-session/source-revision admission claim. No merge attempted by Planck after parent requested review.

@trissim

trissim commented Oct 5, 2026

Copy link
Copy Markdown
Collaborator Author

Parent reviewed determining four-file diff at d0e0475 after normal integration of main4d7f18858: existing ProcessMemoryReceipt owns observed kernel accounting; RetentionMetric annotations derive natural slopes and optional final-GC changes; inherited DiagnosticServerSpec preserves ordinary process/import lifecycle; health consumes the existing typed decoder instead of re-decoding a nominal result. Read committed actual-receiving receipt plus original LIVE-ACCEPTANCE02.json/live02.json/time and controls02.log. Original 30 samples confirm three natural round ends 396696/397128/397444KiB, one final GC event, 374KiB/round slopes, zero GC delta and no failure. Exact MCP1737168 currently absent. Thirteen controls passed. Useful installed diagnostic repair accepted; no science-process adoption, no uncertain revision replay, no proof of long mixed-request retention or issue131 closure. CI remains deferred.

@trissim
trissim merged commit 725fdd4 into main Oct 5, 2026
0 of 3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants