MacResilience & SpaceTrace

Development biography · earlier archive

Development profile compiled from project source and retained records in October 2026. Dates and test results describe those records; they do not imply a new build, live acceptance test or public release.

MacResilience

Project biography

MacResilience addresses a problem that becomes especially visible when several coding agents work alongside a person: useful work stops fitting neatly into one branch. A feature may exist in a committed worktree, a correction may remain unstaged, an experiment may be untracked, and a dependency may live outside the application repository. Deleting an apparently idle checkout or merging the newest branch can therefore lose something important. The project's documented motivation is to consolidate the studio’s AssistantApp estate without losing its work.

Its central idea is that cleanliness, preservation and correctness are different questions. A clean checkout can contain commits missing from the chosen destination. A successful build does not prove that all source variants were considered. A commit does not preserve untracked files, important ignored data or agent scratch. MacResilience makes these distinctions explicit rather than rolling them into a single readiness badge.

A developer begins by choosing an integration target and identifying candidate sources. Repository identity matters: discovery uses the common Git repository, not a similar folder name. The evidence collection separates committed, staged, unstaged, partially staged and untracked work. Content-sensitive fingerprints bind observations to what was actually read, so a later edit is a reason to refresh evidence instead of trusting a stale report.

The path dossier is the accounting view. It records topology, merge bases, source changes, target-owned work, overlaps and outstanding decisions. It is paged, and complete review requires following those pages to their end. A semantic matrix complements it by comparing Swift declarations and their relationships. This can help identify an implementation repeated under another path or a declaration that changed in two sources. It does not replace the path inventory: resources, settings, binary files, deletions and files without parsed declarations still matter.

Preservation is deliberately broader than an ordinary Git patch. The documented snapshot process retains repository metadata and relevant checkout content, hashes copied material, verifies the output and records incompleteness. A snapshot with unreadable or mismatched content is not silently accepted. Restoration targets a new location rather than overwriting the original. These mechanisms support a recoverable workflow; they are not a promise that every possible filesystem or storage failure can be repaired.

Once a bounded change has been selected, the workflow moves from observation to proposal. Declaration transplants, carried files and other supported operations are represented by plans and bundles. The guarded execution surface is a designated integration checkout. Approval is content-bound: a human approves a particular plan digest, not an open-ended instruction to do whatever seems appropriate. The journal records writes and their undo information. Original source checkouts remain preserved, while retirement is treated as another decision requiring fresh evidence.

A concrete journey might start with two agents having improved the same UI component differently. The developer discovers the related worktrees, examines each layer of work, preserves the relevant state, and opens the competing declaration details. The reviewer identifies the canonical intent and supporting dependencies, explains unresolved overlap, and prepares a small phase. The person then reviews its exact effects before approval. Validation follows application in the isolated target; build, test and runtime results remain separate receipts.

The ccx MR Phase Review integration extends this approach to Claude and Codex coordination. It is designed to pass a scoped MR packet through independent review and stop before human approval. A review finding is not an agreement, and comments cannot clear missing evidence. This integration is implemented and has substantial scratch-fixture evidence, but its native-client completion gates remain open in this chat's record.

MacResilience is therefore best presented as a working local engineering system with unusually explicit safety and provenance boundaries. Its distinctive contribution is the connection between inspection, preservation, scoped authority and verification—not autonomous merging or automatic cleanup. Readers should understand that the person remains responsible for judging intent, addressing unknown evidence and approving changes.

Foundations and modules

• StorageObservationCore: filesystem observations, repository/checkouts and consolidation logic; SQLite linkage.
• MacResilienceEvidence: persisted evidence with SQLite and deterministic CBOR-related representation through local Swift-CBORLD.
• MacResilienceReasoning: evidence-grounded reasoning services.
• TahoeSpaceTraceBridge: local APFS package's MacResilienceCompanionCore integration.
• mac-resilience CLI and mac-resilience-mcp: terminal and agent-facing surfaces.
• SwiftProjectAnalyzer: external declaration-analysis helper; parser evidence is not compiler/type-resolution proof.
• SemanticCompute: separately scoped verification helpers; do not imply every operation is GPU accelerated.
• ccx: separate coordination/review project, not the author of all MR functionality.

Maturity and evidence

Source is implemented and historically packaged/installed locally. The canonical checkout's BUILD-REPORT records 0.26.1 build69 installed 28 September from c0a02a0, with 133/134 acceptance checks passing: functional checks passed, repository-stability control failed under concurrent writes; this is not clean acceptance. A separate 0.28.1 staged candidate and test receipts exist on TOSHIBA. Its 10 October acceptance.log ends with external SpectralProcessor drift, INVALIDATED and exit1. No fresh install/runtime verification was performed for this biography. Do not collapse these different checkouts/builds into a current release claim. No verified public download or supported distribution channel identified.

Roadmap and limitations

Close valid runtime acceptance; complete genuine native-client Phase Review handoff; refresh preservation and runtime pins; maintain visible coverage gaps and source-bound approvals. Applied/proven receipt import into ccx is described as a later phase. Unknown/truncated evidence remains blocking. No guarantee of automatic semantic equivalence or safe deletion.

FAQs

Does it automatically merge everything? No. Scoped changes require explicit review and human agreement. Is a clean Git status enough? No; target-relative committed work and non-Git material can still be unique. Can agents approve their own plans? The documented review boundary stops before the person's MR agreement. Can it restore over my original checkout? The preservation protocol restores into a new folder; replacement is a separate decision.

SpaceTrace

Project biography

SpaceTrace begins with a practical question: where did the space go? A developer's Mac can accumulate build outputs, agent worktrees, cloned repositories, temporary analysis and application data faster than a static folder-size list can explain. The original documented application reconstructs recent file activity, captures a baseline and compares allocated disk usage over time. Its later development connects that storage perspective to the provenance of engineering work.

The first-launch lookback uses metadata on files that still exist. It distinguishes arrival at a directory from content modification and labels weaker creation-date fallbacks. This is an important limit: the app does not claim to recover files already deleted, historical sizes that were never measured, or the process responsible for every past write. The absence of that evidence remains visible rather than becoming a confident attribution.

A baseline provides a firmer reference. SpaceTrace compares allocated bytes and offers non-overlapping child-folder growth, large changed files, hotspots and time-series views. Allocated size is useful for sparse files, but it still cannot perfectly distribute APFS clone sharing, purgeable capacity or snapshot-exclusive storage among ordinary file paths. The application therefore retains separate numbers for volume space consumed, growth found inside the scanned location, and the difference the scan cannot explain.

Live monitoring adds FSEvents after monitoring begins. The events can reveal creation, modification, removal, rename, clone and metadata activity. They are signals rather than a complete byte ledger. When a prior size is unknown or an event cannot support a defensible delta, the app calls for reconciliation instead of inventing one. Periodic full scans remain part of the design because fast event feedback and authoritative accounting solve different problems.

For a typical storage investigation, a person chooses the home folder or another explicit location, examines recent activity, captures a baseline and enables monitoring. If free space falls, they follow the growth views into a particular subtree and reveal a file in Finder. The useful outcome may simply be an explanation. A large or newly changed path is not automatically a cleanup recommendation.

The Workspaces and Checkout Changes surfaces add a developer-specific layer. A path can be related to a repository, branch, checkout or agent-managed workspace. Selected checkouts expose staged, unstaged, untracked and partially staged changes, with bounded code details loaded when needed. Source-hygiene suggestions identify lexical candidates such as empty Swift files or commented-out code, but the documentation repeatedly distinguishes a review footprint from guaranteed disk savings. A file can look redundant and still carry history, target membership or unique work.

MacResilience supplies the underlying evidence and guarded operations. SpaceTrace is the native interface, not an unrelated implementation of repository safety. Dossier and semantic views help a person understand overlaps and proposed integrations. Later build reports document guarded Apply support through the same MR plan-step authority and journal as the MCP surface. Observation is read-only; deliberately approved integration is a separate guarded workflow.

The in-app assistant adds explanation without making model output authoritative. Documented routes include deterministic Evidence only, local loopback MLX and Apple's on-device model where available. The evidence canvas presents the question, supporting observations, bounded inference and proposed next measurement. Availability and fallback are part of the story: users should not be told a particular local model is always present or that the application trained its own model.

SpaceTrace also includes diagnostics and optional exact-integer verification. Synthetic aggregation checks and SemanticCompute receipts help investigate numerical correctness, including integer values beyond ordinary floating-point exactness. Such results must remain tied to their workload and helper identity. They do not justify a blanket performance claim about every scan, disk or Mac.

The intended audience is developers and technically curious Mac users who want to understand changing storage, especially in complex local development estates. Its strongest presentation is an inspectable chain from disk growth to file activity to workspace context. It is not a one-click cleaner. Its value lies in reducing guesswork while retaining the user's control over what happens next.

Features and foundations

Native SwiftUI app with WebKit evidence canvas; depends on the sibling MacResilience package's StorageObservationCore, MacResilienceEvidence and MacResilienceReasoning products. Existing authored surfaces include Recent Activity, baseline/growth monitoring, Live Events, Workspaces, Checkout Changes, dossier/semantic investigation, source-hygiene review and diagnostics. App Intents/Shortcuts are documented; operating-system discovery depends on indexing and installation state. Local package/helper contributions must be credited separately rather than implied to be all authored within SpaceTrace.

Maturity

Historical local installation and component tests are recorded in SpaceTrace/BUILD-REPORT.md: 0.26.1 build69 installation on 28 September; 38 XCTest cases with six opt-in renders skipped plus19 Swift Testing reported. Older README reports packaged Evidence-only canvas runtime checks, but this biography did not repeat them. Shared MR acceptance caveats above apply. Native screenshots, current launch state, distribution licensing and supported public release are not verified by this read-only handoff.

Roadmap and limitations

Finish runtime acceptance under stable inputs, keep UI coverage and bounded paging honest, complete reviewed scoped integration workflows and obtain publishable demonstration assets. Privacy permissions affect scan coverage. FSEvents lack responsible-process and complete byte attribution. Parser/lexical suggestions need human judgement. No arbitrary cleanup, autonomous deletion or universal disk-attribution claim.

FAQs

Is it a disk cleaner? No; its primary role is observation, explanation and evidence-led investigation. Can it explain every missing byte? No. APFS snapshots, sharing, privacy and purgeable accounting can leave a visible unexplained difference. Does recent activity recover deleted history? No; initial history is metadata reconstruction of still-present files. Must I run an AI model? No; the documented Evidence-only route is deterministic, with optional availability-gated local reasoning. Can it change source? Later releases expose MR's deliberately approved, guarded integration operations; ordinary inspection and source-hygiene suggestions do not authorize edits.