security: bind OAuth connection publication to stable directory authority

[seonghobae]

Buyer/security gap

Provider-OAuth connection documents must not trade same-object publication authority for pathname convenience. POSIX renameat() constrains namespace resolution with directory descriptors but still consumes a source pathname; that is not proof that final mutation consumed the exact opened/reviewed source object. DiskSage therefore keeps existing-record replacement unavailable rather than presenting repeated pathname checks as exact-source-object mutation.

Current exact owner evidence — 2026-09-09 KST

• protected main: 0e90f9cebadbd7f59606baaec4ca1d2f178c899a;
• release/Test prerequisite fix: verify Windows release artifact namespace #264: 90ca44841891d98615b11117de0f35adf917cc31; Release/Test/SAST/Security are terminal GREEN. Required CodeQL/OpenCode/Noema/Strix and one-human-approval governance remain non-passing;
• reusable filesystem owner security: restore object-bound private evidence publication #344: e72f75d273f01a63a04b24ac421de9ed99734c44, open/Draft and exact-head GREEN. Test 34163872423, SAST/Security/Secret Scan/Docs are terminal success;
• provider-OAuth security: reject unknown OAuth connection authority fields #339 exact f32eba19df3f8e087cc1390d074d3d844f22ba01 is ordinary/non-force on exact security: restore object-bound private evidence publication #344. Its predecessor 450772c9... reproduced the Ubuntu full-Rust-suite RED four times; attempt-4 job 102334279549 identified a rustfmt-sensitive source-contract assertion although production already obtained metadata and bounded bytes from the same opened File handle. f32eba19... fixes only the test; production authority is unchanged. Exact Test 34314249490 is terminal SUCCESS;
• operational CLI/process owner fix: make cloud operational help a successful terminal action #212 is now exact 8b1edb0e079a72fa6fa9a803fb46075266f987b8, ordinary two-parent non-force on exact security: reject unknown OAuth connection authority fields #339, with its 13-file CLI delta retained. Test 34317460873 is non-terminal: Windows home-resolution 102356579751 and real llama.cpp CPU/FFI 102356579596 are GREEN; Ubuntu full Test 102356579555 remains in progress;
• fix: make cloud operational help a successful terminal action #212's leaf .github/workflows/provider-oauth-windows.yml has produced no Actions run on the inspected predecessor/current fix: make cloud operational help a successful terminal action #212 heads. That cannot be counted as Windows provider-process evidence and is also a shared-Test single-writer violation;
• canonical Test owner fix(ci): repair contract-doc path filtering #338 is exact 8b0e2b529bff0640cef87e2aa7b6c15f40c28655, ordinarily restacked onto exact fix: verify Windows release artifact namespace #264. Test-first 13aa167... requires Windows provider_oauth_cli_process whenever its owner source exists; exact 8b0e2b... adds the canonical conditional execution. Test 34318110278 is non-terminal: macOS 102358542894, Windows 102358543010, and real llama.cpp CPU/FFI 102358542989 are GREEN while Ubuntu 102358543004 remains in progress. The Windows log explicitly says SKIP provider_oauth_cli_process: owner test source absent; no runtime regression executed, so this owner head has workflow-admission evidence only;
• canonical docs docs: establish canonical DiskSage product requirements #315 advanced to 8eff6c663af94a1cce140a277af920e0f8ba02cc and now records the current security: reject unknown OAuth connection authority fields #339/fix: make cloud operational help a successful terminal action #212/fix(ci): repair contract-doc path filtering #338 topology in docs/product-technical-gap-baseline.md. Predecessor 99eee633... Test 34314459845 is GREEN; fresh successor Test 34318708189 is queued and predecessor evidence does not transfer.

Authoritative platform contract

POSIX.1-2024 rename()/renameat() are pathname operations; directory descriptors constrain resolution but do not turn a source pathname into an opened-file-handle precondition. Linux O_TMPFILE/linkat(..., AT_EMPTY_PATH) are platform-specific and do not by themselves provide a portable existing-destination replacement contract.

• POSIX.1-2024 rename()/renameat(): https://pubs.opengroup.org/onlinepubs/9799919799/functions/rename.html
• POSIX.1-2024 open(): https://pubs.opengroup.org/onlinepubs/9799919799/functions/open.html
• Linux renameat(2): https://man7.org/linux/man-pages/man2/rename.2.html
• Linux open(2) / O_TMPFILE: https://man7.org/linux/man-pages/man2/open.2.html
• Linux linkat(2) / AT_EMPTY_PATH: https://man7.org/linux/man-pages/man2/link.2.html

Microsoft exposes handle-oriented rename metadata through FILE_RENAME_INFO.RootDirectory and SetFileInformationByHandle(FileRenameInfo), but DiskSage still needs a complete design binding temporary creation, final replacement, reparse handling, cleanup, ACL/privacy policy, and durability to accepted native handles.

• Microsoft FILE_RENAME_INFO: https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-file_rename_info
• Microsoft SetFileInformationByHandle: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfileinformationbyhandle

On macOS, namespace atomicity, fsync, and stronger device-flush semantics remain distinct; claims must match the primitive actually exercised.

• Apple fsync(2): https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/fsync.2.html
• Apple fcntl(2) / F_FULLFSYNC: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/fcntl.2.html

Current #344 contract

Production fail-closes existing-record replacement when exact-source-object mutation cannot be proved. Create-new publication remains separate and retains exact private-mode admission, descriptor-relative no-follow authority, absolute destination/policy boundaries, exact opened/final identity and byte verification, bounded final reads/serialization, exact-private parent requirements, and descriptor-bound cleanup. Missing-parent pathname provisioning and delete-and-create replacement are not authorized shortcuts.

Remaining RED/GREEN acceptance

1. fix(ci): repair contract-doc path filtering #338 exact 8b0e2b... must first earn terminal current-head GREEN. Source-absent Windows success is not provider runtime evidence.
2. After fix(ci): repair contract-doc path filtering #338 GREEN, fix: make cloud operational help a successful terminal action #212 must adopt it through ordinary non-force ancestry, remove the competing leaf provider-oauth-windows.yml, and its resulting exact Test must execute provider_oauth_cli_process from source on Windows and finish GREEN. Predecessor Windows evidence does not transfer.
3. fix: make cloud operational help a successful terminal action #212's Ubuntu full Test on the resulting exact head must also be terminal GREEN before CLI/process/platform readiness.
4. First-create behavior stays distinct from replacement. Failure cleanup must never pathname-unlink an unrelated replacement object.
5. Unix durable connection-document load admission remains exact 0600; error classification must not turn pathname metadata into read/mutation authority.
6. Any future Unix/macOS enabled replacement must prove at the final identity-check→mutation boundary that the object mutated is the exact reviewed source. Another pathname recheck is insufficient.
7. Windows must pin directory/file namespace authority with native handles through temporary creation and final replacement, reject reparse drift, enforce private ACL policy, define data/namespace flush behavior, and fail closed when unavailable.
8. macOS evidence must name the persistence primitive actually exercised and not claim stronger power-loss durability than demonstrated.
9. Existing destination symlink/reparse/non-regular, ancestor replacement, mode/content drift, cleanup substitution, permission/resource failure, and partial-failure scenarios remain fail closed.
10. No source copy into fix: make cloud operational help a successful terminal action #212 or sibling services; DiskSage retains filesystem invariants through owner contracts. Exact-head applicable Test/Release/Security/SAST/CodeQL/coverage/review evidence must be terminal success before integration.

Close only after #212 inherits the exact current owner contracts with its own source-present GREEN evidence, Windows parity is addressed for every exposed update path, and any future enabled replacement has adversarial real-filesystem exact-source and durability evidence.

[seonghobae]

2026-09-05 exact-owner progress: #339 advanced non-force from a72a4fa6830e1ac6eb54a4b477d3e5b88000de87 to 9ec8d17d909a83ccdc83d5cff528716e9ce5d37b with src-tauri/tests/provider_oauth_publication_authority_contract.rs. This is deliberately RED-first: it requires openat/renameat/unlinkat, an explicit containing-directory sync failure contract, and removal of the current pathname std::fs::rename(&temporary, path) publication. The current production save_connections() still uses pathname temp creation/replacement and therefore does not satisfy this test yet; #342 remains open and #339 remains Draft.

This source contract is not being counted as the required adversarial filesystem acceptance. GREEN still requires real temporary-filesystem parent replacement before temp creation and between temp sync/final publication, plus the Windows handle-relative creation/rename/write-through boundary and an explicit macOS persistence choice. #212 was then non-force restacked to 24a03c5e4aafccac259683f8f634a7e657c88039; its net CLI/process delta remains unchanged and it does not copy #339's implementation authority.

[seonghobae]

Current-lineage foundation repair has advanced without closing this issue.

• fix: verify Windows release artifact namespace #264 release/Test prerequisite: 5c4eedeb6a2f48ddf9030c18d970fedf85dda2ac.
• New Draft prerequisite security: restore object-bound private evidence publication #344 exact head: aebaab1070d3900b286aba4e3e2111c457931030, non-force descendant of fix: verify Windows release artifact namespace #264.
• security: restore object-bound private evidence publication #344 first restores the final reviewed security: bind private evidence publication to directory identity #228 object-bound create-new primitive onto the current lineage, then adds object_bound_publication.rs: on Unix temporary creation is openat-relative to one pinned directory descriptor, cleanup is unlinkat-relative, replacement is renameat-relative, the temporary record is synced before publication, and the directory is synced after rename. Real temporary-filesystem hooks replace the visible parent before temp creation, after temp sync, and after rename; replacement-directory bytes are never targeted. Post-publication namespace drift is reported separately because publication to the admitted object may already have occurred.
• Windows deliberately returns an unsupported/fail-closed result in this new replace primitive. There is no pathname fallback. Microsoft documents FILE_RENAME_INFO.RootDirectory as a relative rename authority, but temporary creation still needs equivalent handle-bound namespace authority; fixing only the rename half remains insufficient.
• security: reject unknown OAuth connection authority fields #339 has been non-force restacked on security: restore object-bound private evidence publication #344 at c05b5daaa0ce2297402978407afa20b45702185a; fix: make cloud operational help a successful terminal action #212 has been restacked on security: reject unknown OAuth connection authority fields #339 at 9dbf81a5eb373114bde7084581038d74ce0fbf6c without copying provider-domain or foundation source.

This is foundation progress, not #342 GREEN. save_connections() on #339 still uses pathname temporary creation/remove/rename and has not yet mapped object-bound directory-sync/post-publication uncertainty into the OAuth domain contract. The retained provider_oauth_publication_authority_contract.rs therefore stays RED. #342 remains open until #339 consumes the primitive with domain-level adversarial fixtures and Windows handle-relative parity, followed by unchanged-head GREEN evidence.

[seonghobae]

2026-09-05 current-owner progress:

• security: reject unknown OAuth connection authority fields #339 repaired its publication contract so the domain consumer no longer demands a second copy of security: restore object-bound private evidence publication #344's low-level openat/renameat/unlinkat implementation. The contract now requires consumption of crate::object_bound_publication::replace_object_bound_bytes, stable OAuth-domain failure mapping, and absence of pathname staging/remove/rename bypasses (ac130fa035ca8f4ed809c39f41c171b5b91ac775).
• security: reject unknown OAuth connection authority fields #339 production now routes save_connections() through security: restore object-bound private evidence publication #344's canonical object-bound replacement primitive and maps directory-sync failure, post-publication namespace uncertainty, and unsupported-platform failure explicitly (4ec4f8e0dff131d307be887576bed335c394adb6). The predecessor pathname OpenOptions temp creation, pathname cleanup, and std::fs::rename publication were removed from the domain owner.
• This is intentionally not issue completion. Windows still fails closed because security: restore object-bound private evidence publication #344 has no native handle-bound temporary-create + replace parity, and deterministic OAuth-domain ancestor-replacement fixtures are still missing. The superseded RED commit did not reach an Ubuntu failing test before cancellation, so no runtime RED is claimed from that run.
• Descendant fix: make cloud operational help a successful terminal action #212 was non-force restacked. A first same-tree restack exposed stale provider-domain blobs in the CLI tree; 9cbb642f62fe313a920308b54db63a97db245fc2 explicitly adopted security: reject unknown OAuth connection authority fields #339's repaired provider_oauth.rs and publication contract. Fresh security: reject unknown OAuth connection authority fields #339→fix: make cloud operational help a successful terminal action #212 compare has merge base exactly 4ec4f8e... and no provider-domain file delta.
• Canonical docs owner docs: establish canonical DiskSage product requirements #315 updated docs/product-technical-gap-baseline.md at a5722716eaf8fc1d467520d9f5f82a99c19e8e94 to reflect the consumer repair while keeping this issue open for domain race evidence and Windows parity.

Next acceptance remains: real OAuth save-boundary parent-replacement fixtures around temporary creation/publication, then Windows native handle-bound publication with no pathname fallback, followed by unchanged-head GREEN.

[seonghobae]

2026-09-06 KST owner-contract update: reusable filesystem owner #344 is now exact 14f08b74e6cefdb9605c2c1868cd01d3f1945d90. Fresh test-first d4d789221e02a6380ecbd0fb0839f122aa9527fd adds unsupported owner-only mode cases (0000, 0100, 0200, 0300, 0500, 0700) to the replacement boundary; production 14f08b74... admits only the private-record modes 0400 or 0600 and otherwise returns object-bound-replace-mode-invalid before capability evaluation. Existing-record replacement remains intentionally unavailable because final mutation is not yet bound to the exact reviewed source object. Exact Test 33997557978 is still non-terminal, so #339 remains on last terminal-GREEN owner 280a0059...; fresh current-owner compare has merge base 280a0059..., behind_by=8. Do not restack #339/#212 until current #344 GREEN and then current #339 GREEN. Windows native-handle create/replace/reparse/durability parity and any future exact-source replacement/recovery acceptance remain open.

[seonghobae]

Fresh owner delta — 2026-09-06 KST

Reusable filesystem owner #344 is now exact 10a81c69a09e09859a837e3c03ff79916f27ab92. The create-new wrapper itself had an inconsistent mode boundary: forbidden_root=None reached private_directory_publication and admitted only 0400 | 0600, while forbidden_root=Some(...) delegated arbitrary unix_mode to the lower-level core. That allowed a 0644 create-new request outside the forbidden root despite the private-record contract.

Real-filesystem RED 0b58c24b5936711c64a66cfb080b0564cdc69848 requires 0644 to return ModeInvalid with no target created. Production 10a81c69a09e09859a837e3c03ff79916f27ab92 performs 0400 | 0600 admission before either wrapper branch. Existing-record replacement remains unchanged and fail closed.

Exact #344 Test 34021030040 remains non-terminal: Windows is success; Ubuntu test and llm-engine-build are runner-unassigned queued. #339 therefore remains exact b0c523a... on merge base 280a0059..., now behind_by=10, and #212 must continue waiting. No predecessor GREEN transfers and no unsafe fallback is authorized.

[seonghobae]

Fresh owner update — 2026-09-06 KST

#344 is now exact b70b0ad9a5789730a389c2027a8bb4d593e08782. After the earlier forbidden-root wrapper repair, review found that the deterministic hook seam still exposed the lower-level core helper broadly enough for crate-internal code to request 0644. d4f514eb...→fa917cbe... guards the reusable seam. A follow-up direct-core test 49151b0914a7d33d0fa7b1b637d5820cd4caa997 proves the core mutation boundary itself must reject 0644 before any hook or filesystem work; production b70b0ad9... now enforces 0400 | 0600 at the start of write_object_bound_bytes_create_new_with_hooks.

The intermediate Test runs were superseded/cancelled, so hosted RED is not claimed. Exact #344 Test 34023764605 remains non-terminal and Release 34023764625 is skipped. No Ready/merge or consumer adoption is authorized yet.

Fresh compares: #339 b0c523a... and #303 673a7a1... both retain merge base 280a0059... and are behind_by=14 versus current #344. #339 remains on the last terminal-GREEN filesystem owner; #212 remains downstream and must wait for #339 to adopt a GREEN current #344 and then earn its own GREEN.

This does not change the completion boundary: existing-record replacement remains unavailable; Windows native-handle replacement/publication parity and any future exact-source Unix/macOS replacement/recovery contract are still required. Canonical product-gap projection is updated on #315 at 6a896703a5892c4140bac0fdc3a42ff59a3e2102.

[seonghobae]

2026-09-06 owner-contract update: #344 is exact c289a110c6abd2d6ab0d6f307b5c76b582fa056f. The latest repair is test-layer, not broader filesystem authority: a stale replacement special-mode contract still searched production source for the old unix_mode & !0o777 / unix_mode & 0o077 implementation even after the owner deliberately moved admission to exact 0400 | 0600. c289a110... makes that contract behavioral: special-bit requests (01600/02600/04600) return ModeInvalid before record/staging mutation and 0600 still fails at SourceIdentityUnavailable. No hosted RED is claimed because the predecessor run had not executed the stale contract. Exact Test 34024727776 remains non-terminal (Windows success; Ubuntu test/llm-engine-build runner-unassigned/queued). #339 stays exact b0c523a... on last GREEN owner 280a0059...; fresh compare to current #344 is merge-base 280a0059..., behind_by=15. Adopt current owner only after unchanged-head GREEN, then reacquire #339 evidence before #212 follows. Windows native-handle replacement/publication and future same-source-object replacement remain unresolved.

[seonghobae]

2026-09-06 KST owner evidence update

#344 is now exact 6f934ebf87061432a0fb89ff3237aaefb687a367. The prior a593247...→edeaeb76... repair binds/revalidates the forbidden/source-root directory identity across create-new publication. A subsequent same-UID review found the no-policy private-directory helper still used mkdirat() to create a missing child and only then openat() the child pathname. Since mkdirat() returns status rather than the created directory descriptor, that interval cannot prove the opened child is the object DiskSage just created. Test-first 39eec7f7bd637f6aea651b328b497d7eb0e6e373 requires a missing-parent request to fail with no ancestor/record mutation; its hosted Test 34026935102 was cancelled by the immediate successor, so hosted RED is not claimed. Production 6f934ebf... removes create-then-open ancestor provisioning: the final parent must pre-exist at exact 0700, is opened O_NOFOLLOW, bound by device/inode, and revalidated before/after publication.

Exact #344 Test 34027050887 is non-terminal. #339 b0c523a... retains merge base 280a0059... and is now behind_by=19; do not adopt until unchanged-head #344 GREEN, and preserve the narrowed parent-authority contract during adoption. Windows native-handle replacement/publication parity and future enabled exact-source replacement/recovery remain open, so this issue stays open.

[seonghobae]

2026-09-06 KST exact authority refresh: #344 83348151f82b056a70935cfea9aedbbdb1b39cc8 now has terminal GREEN Test 34029178543. The current contract still admits forbidden/source-root target identity before the earliest publication hook, requires later opened/revalidated object identity to match, restricts private modes to 0400 | 0600, and keeps existing-record replacement unavailable before mutation when exact source-object replacement authority is absent. #339 non-force adopted that owner at 7702d3c2f12aabf72992bb0d146f64490f0ffa73 and #303 at c37dcfa453206b5326828daf7a9a295e263f68b7; both compare behind_by=0 from #344, but Tests 34032018781 / 34032041247 are still queued. #212 therefore remains downstream and un-restacked. Windows native-handle replacement/reparse/durability parity and any future exact-source replacement remain open; no pathname/delete-and-create fallback was introduced.

[seonghobae]

2026-09-06 KST owner-state correction / new repair evidence:

• protected main remains 0e90f9cebadbd7f59606baaec4ca1d2f178c899a;
• current reusable filesystem owner security: restore object-bound private evidence publication #344 is d381434fc96c4676e42b27c2c9df26c29e595e10, not the older 83348151... snapshot in the issue body;
• last terminal-GREEN security: restore object-bound private evidence publication #344 checkpoint remains 83348151f82b056a70935cfea9aedbbdb1b39cc8 with Test 34029178543;
• intervening 2c09ee448795a718658f1800640818a8fe3ffb6f → 7b91e7bb61c1b00f39406f1e4f8729952703b5aa adds final same-object byte-content revalidation to both reusable create-new publication paths;
• test-first a49d70420c13abf614ba45eb2cd64c30ca446424 proves public source_root could still be relative and therefore resolve through ambient process CWD. Production d381434fc96c4676e42b27c2c9df26c29e595e10 adds ForbiddenRootInvalid / stable private-evidence-source-root-invalid and rejects relative forbidden/source-root authority before parent/source-root filesystem lookup or any hook;
• exact current security: restore object-bound private evidence publication #344 Test 34033517542 is non-terminal: Windows 101487329365 succeeded; Ubuntu test 101487329256 and llm-engine-build 101487329301 remain runner-unassigned (steps=[], runner_id=0). Current-head GREEN is not claimed;
• security: reject unknown OAuth connection authority fields #339 is 7702d3c2f12aabf72992bb0d146f64490f0ffa73 and feat: evidence-bound provider cache reclaim #303 is c37dcfa453206b5326828daf7a9a295e263f68b7; both adopted last GREEN 83348151... and are now behind_by=4 current security: restore object-bound private evidence publication #344 with merge base 83348151.... They intentionally remain unchanged until current security: restore object-bound private evidence publication #344 is terminal GREEN. fix: make cloud operational help a successful terminal action #212 remains downstream of security: reject unknown OAuth connection authority fields #339.
• canonical docs docs: establish canonical DiskSage product requirements #315 is now 9d5eeee5a2d817be479a3c2ab6e2a10e913e97eb and the gap baseline records this state.

Existing-record replacement remains fail closed. This repair narrows policy-root admission only; it does not add pathname replacement, deletion, or Windows mutation authority. Windows native-handle parity, macOS durability scope, exact-source enabled replacement, and cross-platform recovery/undo remain closure criteria.

[seonghobae]

Additional #344 repair after the source-root admission fix: lower-level no-policy publication now emits private-directory-publication-file-content-drift when the final same object retains identity/mode but its bytes or length change. The reusable facade did not map that new causal class and therefore flattened it through the default ParentUnavailable branch. Test-first 57dc213579fbb2401e0c24fb991ed0259b040c17 requires RecordContentDrift; production 20177e3a92c6b3dcdd2996ab0e3fd8c5f23145be adds only that mapping. Filesystem mutation/cleanup authority is unchanged.

Current #344 exact Test is 34033941941 and remains non-terminal, so no owner GREEN or consumer restack is claimed. #339/#303 remain on last GREEN 83348151... and are each behind_by=6 current owner. Canonical docs #315 is b7e762169cd46f75f1a91280fb149e8139738fa8. Windows native-handle replacement/publication and cross-platform recovery closure criteria remain unchanged.

[seonghobae]

2026-09-06 KST owner-path refresh: reusable filesystem authority #344 current exact head is 16666be2af97a2c0efedc6e56bd56314ad081167. Test-first 925824b97d4db755491326c6ac3ffda3593c325e uses real Unix FIFOs to prove that final pathname identity inspection must not block when the just-published visible name is replaced before finalization. 53361fb2c9e7899b1e5f26ca3c21ed8e5bcb3133 adds O_NONBLOCK to the no-policy descriptor-relative final reopen; fresh review found the source-policy sibling still used blocking O_RDONLY, so 16666be2... applies the same minimal fix. The security contract is unchanged: final success still requires regular-file type, exact dev/ino, exact private mode, exact length, and exact bytes, while unrelated replacement pathnames are not unlinked or mutated.

Exact Test 34040916822 currently has Windows success and Ubuntu test/llm-engine-build runner-unassigned queued, so 16666be2... is not yet GREEN and no downstream restack/merge is authorized. #339 7ac4ccc... and #303 68ac5af... adopted only predecessor exact-GREEN 20177e3a...; their exact Tests are now terminal failures and need independent RCA plus later current-owner adoption.

Keep this issue open. Windows native-handle publication/replacement parity, an accepted exact-source-object primitive for existing-record replacement, same-object Trash/irreversible mutation, durable journal/receipt, crash/power-loss recovery, and undo remain P0 acceptance conditions.

[seonghobae]

2026-09-07 KST owner refresh: reusable filesystem authority is now #344 exact 2b2fbef09aac1bec553b3168397e9d7132f90f2f. Fresh review found that the no-policy private-directory facade could normalize an absolute raw destination ending in / into the same final file target. Test-first 476b578bc0f24c123176e1e6e328453c34f8ab5b requires private-directory-publication-path-invalid, zero hook calls, and no target creation; its hosted Test 34042976714 was cancelled by the immediate successor, so no hosted RED is claimed. Production 2b2fbef0... rejects the trailing Unix separator before parent lookup/hooks/mutation. Exact Test 34043094733 has Windows terminal success; Ubuntu test (101513244613) and llm-engine-build (101513244724) remain runner-unassigned queued, so current #344 is not GREEN. #339 7ac4ccc... and #303 68ac5af... still contain last exact-GREEN owner 20177e3a... and are five owner commits behind; no restack until current #344 GREEN. The source-policy core still needs the equivalent raw trailing-separator admission contract. Windows native-handle replacement/publication, exact-source existing-record replacement, same-object deletion/recovery, durable journal and undo remain open; macOS durability claims remain limited to the primitive actually exercised (fsync is not silently promoted to F_FULLFSYNC).

[seonghobae]

2026-09-07 KST exact filesystem-authority update: #344 current 1d73810578bdc93e4cce31458b42c6897a28006e. Two reviewed final-read resource-exhaustion findings are repaired without widening mutation authority: 9067b73f... requires a bound, 523bd73a... and 02bd0603... cap final descriptor reads at expected length + 1 and retain the existing content-drift result for any extra byte. Source-policy raw trailing-separator authority is now symmetric with no-policy publication: real-filesystem/hook-count RED 2dfa42ff..., production 1d738105... rejects a destination ending in raw Unix / before hooks, lookup or create. Exact Test 34044754807 currently has Windows success and both Ubuntu jobs runner-unassigned queued, so current head is not GREEN. Last GREEN owner remains 20177e3a...; #339/#303 share that merge base and are ten current-owner commits behind. Do not infer Windows native-handle parity, enabled existing-record replacement, parent provisioning, Trash/irreversible deletion, or crash/power-loss recovery from these create-new repairs.

[seonghobae]

2026-09-07 KST fresh owner update: reusable filesystem owner #344 is exact 07e8b7b1c92298046c430e2e183ff5f30b4a0073, Open/Draft. Last exact-GREEN owner remains 20177e3a92c6b3dcdd2996ab0e3fd8c5f23145be / Test 34033941941; current owner is fourteen commits ahead. Exact Test 34046044880 has Windows terminal success while Ubuntu test 101521154681 and llm-engine-build 101521154450 remain runner-unassigned queued, so predecessor GREEN is not current-owner evidence.

A new resource-consumption finding was repaired without changing replacement authority. Public private-JSON publication enforced MAX_PRIVATE_EVIDENCE_BYTES = 8 MiB only after serde_json::to_vec_pretty had fully materialized the value. Test-first 199d8c49b864a13fbd41fc52e035e8b076512629 uses a streaming custom serializer and requires stable private-evidence-too-large before target creation and before 50,000 emitted 256-byte elements. Production 07e8b7b1... serializes through a bounded Write sink and reaches the existing object-bound create-new primitive only after the JSON is admitted. Small admitted values preserve the prior pretty-JSON representation, SHA-256 receipt and Unix 0600 contract. No hosted RED is claimed for the immediately superseded test-first head.

Existing-record replacement remains exactly as before: valid Unix/macOS replacement fails before filesystem lookup/mutation with object-bound-replace-source-identity-unavailable; Windows remains unsupported; no pathname/delete-and-create fallback was added. #339 7ac4ccc... and #303 68ac5af... retain predecessor owner 20177e3a... as merge base and are fourteen current-owner commits behind. #212 therefore remains held until current #344 earns unchanged-head GREEN, #339 adopts it non-force and earns its own GREEN. Canonical docs #315 records the current state in dc4a57d3fa1e1df7200b08a86386983bbd50d7a6.