Skip to content

fix: prove integration base - #3

Merged
yaacovcorcos merged 2 commits into
mainfrom
integration-proof
Jul 18, 2026
Merged

fix: prove integration base#3
yaacovcorcos merged 2 commits into
mainfrom
integration-proof

Conversation

@yaacovcorcos

Copy link
Copy Markdown
Contributor

Summary

  • require the recorded integration base to be part of official Synara history
  • continue requiring the same base to be present in Scient-owned history
  • distinguish the two failure messages so evidence drift is diagnosable

Verification

  • git diff --check
  • focused upstream-verifier tests: 5 passed
  • live scient:upstream-check --review-check against fetched upstream

Scope

One verifier invariant only; no desktop runtime behavior changes.

@github-actions github-actions Bot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:XS labels Jul 18, 2026
@yaacovcorcos
yaacovcorcos merged commit d78388a into main Jul 18, 2026
11 checks passed
@yaacovcorcos
yaacovcorcos deleted the integration-proof branch July 18, 2026 10:23
yaacovcorcos added a commit that referenced this pull request Jul 26, 2026
…findings

Ensure the provider updater child process is only ever spawned against a
target that was probed, certified, and re-validated under the settings write
lock, closing six concurrency/security windows in the confirmed-update
boundary:

- #1 Immutable probe/settings snapshot threaded through refresh; a single
  serialized refresh (refreshSemaphore) captures one snapshot and
  revalidates confirmed targets at the commit boundary.
- #2 updateProvider re-validates the confirmed target and captures the exact
  updater command into immutable locals while holding withSettingsWriteLock,
  so a concurrent settings write cannot change what gets spawned between
  validation and capture. The child is spawned OUTSIDE the lock (spawn + await
  share one update-timeout budget), so a slow or hung spawner.spawn — whose
  acquire is uninterruptible — can only stall its own request and can never
  pin the global settings write lock.
- #3 Request-owned update state (per-request owner token); a losing
  duplicate cannot clobber the in-flight update's running state.
- #4 Interruption-safe cleanup lands a terminal failed state and kills the
  child via a scoped finalizer.
- #5 Hot getStatuses/stream reads re-derive only a cheap authority key
  (revision counters) instead of the full maintenance context, so reads
  never re-probe CLIs or re-resolve the runtime.
- #6 Runtime target identity tracked by a monotonic per-provider revision
  counter (ProviderRuntimeManager.getRevision), excluded from transient
  install-progress churn; PROVIDER_KINDS derived from ProviderKind.literals.

Adds deterministic regression tests for each finding (no sleeps; barriers via
Deferred / TestClock.withLive / scheduler drains), including a mutation-
sensitive hot-read guard, a mutation-sensitive guard that the settings write
lock is released before the unlocked spawn, a hung-process timeout guard,
succeeded/unchanged post-update re-probe guards, and a per-provider
revision-isolation test.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:XS vouch:trusted PR author is trusted by repo permissions or the VOUCHED list.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant