feat(core): add metadata-only Folderbase capture planning - #25
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
while keeping raw
FolderbaseVersiondeserialization non-publicFolderbaseVersionStore::openand opaque metadata-onlyCapturePlanbound to one attested root and its optional current Local Headrecords, depth, paths, object sizes, and identity rechecks
SQLite, Git packs, unknown files, and a 10 GiB sparse file as opaque metadata
.folderbaseignorerules, Core generated defaults,negation, required-marker overrides, protocol-state exclusion, and pre-descent
pruning
resolved path's 128 component ancestors instead of scanning every boundary
evidence
Why
TB-33 establishes the safe read-only planning seam required before any future
capture transaction can seal content or move Local Head. Planning must describe
the real workspace without reading opaque payloads, following links, crossing
nested Folderbase boundaries, or letting inventory size create unbounded work.
Truth boundary
This PR implements only phases 1–3: controlled Folderbase Version encoding,
read-only store/open and metadata planning, and ignore-policy planning.
It does not seal a Folderbase Version, read or persist object payloads, mutate
Local Head, restore content, claim snapshot atomicity or database consistency,
implement sync/cloud/sharing/authorization, or change ADR-0005 from Proposed.
TDD and review evidence
nested boundaries, 10 GiB metadata planning, producer seam, symlink-root
rejection, capability traversal, and the missing bounded boundary index.
maximum-depth target performs exactly 128 ancestor probes.
3d896e2: GO, no P1/P2 findings;all five original traversal/security/performance findings are closed.
Verification
cargo test --workspace --all-features --lockedcargo clippy --workspace --all-targets --all-features --locked -- -D warningsRUSTDOCFLAGS="-D warnings" cargo doc --workspace --all-features --no-deps --lockedcargo check --package folderbase-core --lib --target x86_64-pc-windows-msvc --lockedCARGO_NET_OFFLINE=true scripts/test-package-install.shboundary-index tests
checks
Base:
7f873d1c4fef43d9fb9a1a1385a2f5c314119b75Head:
3d896e266f5857faed8743f74adbd029e6ef75cf