Repository navigation
(OPT) Preserve constructor admission failures through existing typed workspace reporting #845
Description
Source-derived follow-up to #825, discovered read-only at7a87b33115c0cd45b14cac64d7b37e5742503159. No measured token, application-fit or memory gain is established. This is a bounded real-consumer step; it cannot close all of #825 by itself.
The first report::Owner acquisition reserves backing before any report Vec exists (src/workspace_graph/constructor_failure/report.rs:115–141); its initial failure returns Setup (attempt.rs:30–36), then compatibility receiving materializes a Vec (receiving.rs:75–107). A nonempty owned Vec cannot be returned allocation-free at zero available ownership. Preacquiring another owner merely moves that base case unless genuine caller storage already exists.
Carry an opaque initial admission/failure channel through the existing semantic_workspace::reporting::preflight -> preflight_typed -> retaining-source builder -> build_owned_inner -> constructor attempt chain. Extend existing WorkspaceReportFailure privately and use typed builder twins rather than adding an unused endpoint. Preserve received report ownership, complete ordered LegacyMany payloads, and unreceived primary/owner without reclassification or implicit Vec conversion. Retain snapshot/Vec APIs as explicit allocating compatibility routes.
Exact invocation context must survive restoration: build_owned_inner creates its scope at workspace_graph.rs:3911, but diagnostics/invocation.rs:22–32 drops current TLS strings assuming help was already copied. Returning only numeric receipts and formatting after restoration would read another invocation. Move the exact existing context into the carrier, or render before restoration into genuinely authenticated caller backing. Do not clone or recertify the original context allocation as paid.
Acceptance: real existing reporting consumer adopts the typed chain; all six diagnostic fields/order and exact dynamic help remain byte-equivalent through foreign/restored/nested/sticky/multiple-error cases; no implicit compatibility Vec allocation on initial typed refusal. Observe allocations including carrier lifetime/Drop and preserve complete independent old receivers. Authenticate any received owner before borrowing/taking. Explicitly disclose any still-unpaid inline carrier/context/output control storage. No cap change, numeric-limit payer, donor budget, refund, dropped error, fallback allocation disguised as funding, or scope reclassification. Existing compatibility allocation and fully funded output remain #825 residuals; do not close that parent from this subtask. Add only focused owning controls and scoped Clippy at the consolidated batch; regenerate moved pins with actual producers/consumers.
Activity
wsdt commentedon Oct 15, 2026
Read-only design audit at
7a87b33115c0cd45b14cac64d7b37e5742503159: keeping this issue open; no implementation or qualification was performed.The existing real chain is
semantic_workspace::reporting::preflight->preflight_typed-> retaining-source workspace builder ->build_owned_inner-> constructor attempt. An initialreport::Owner::acquirerefusal occurs before its report Vec exists. Replacing that failure with a larger typed carrier cannot certify its new control storage from an already exhausted or absent owner, and acquiring another owner only moves the base case.There is also a strict diagnostic-context boundary. The workspace invocation scope owns the current attribution strings, and restoration drops them. Returning numeric receipts and rendering later would read a different invocation. Moving the original strings would retain the context without cloning, but it does not preserve the original
budgeted_formatacceptance/suppression outcome or fund an outward report. Re-running that formatter under a foreign/restored payer, simulating its allowance with a numeric limit, or rendering different initial-Budget JSON/fields would violate the stated contract.The original renderer can produce one Diagnostic before the compatibility
vec!, while the original scope/payer is still live. That is a possible future boundary only where genuine existing owner storage covers the added receiving controls; the initial unacquired branch must otherwise keep its explicit old compatibility fallback. Received reports must retain their original child-active authentication, LegacyMany its complete original ordered backing, and Unreceived its primary plus owner without reclassification.No already-funded CLI output owner was found. A received-only typed builder twin would add a large parallel API while leaving this initial case and output ownership unresolved, so it is not being shipped as completion. The legacy Vec/output route and whole #825 remain open. Work is redirected to #846's actual CLI writer renderer, which can remove intermediate JSON Strings without claiming zero-budget output funding or changing these constructor diagnostics.
wsdt commentedon Oct 15, 2026
Implemented the existing typed reporting boundary while preserving initial failure provenance and the complete selected diagnostic. All six real public reporting consumers PASS at
8bb9f5b7: two in the 76-check batch, four in the separate supplement. Ten core diagnostic/lifetime/old-receiver controls retain their historical35cc6325PASS status; their bodies and six owning production files are byte-identical at 8bb and were not rerun.Scope is the actual compatibility-Vec removal through the typed boundary. Allocating compatibility/output residuals remain explicit; this does not close #825 or claim fully funded diagnostic output.
Complete published evidence: original 76 = 56 PASS / 20 FAIL; separate supplement = 9 PASS / 0 FAIL. Four build scopes qualify using the explicitly recorded two-command resumption; the original resource interruption remains archived. No full suite or full quality gate ran.
Both consolidated scoped Clippy commands ran and returned 101 for the same unrelated #849
manual_saturating_arithmeticlint atpath_join/boxed_states.rs:63. This is not a Clippy-PASS claim. Its equivalentsaturating_addcorrection is prepared in the next implementation batch. The issue's own acceptance is complete; an unrelated lint or stale graph-budget pins are not added as global closure gates. All 20 current failures remain in the linked archive.