Codespaces is compute. SkyeVault is custody. That is the line I needed the system to respect.
What does it mean for SkyeVault to become the source origin?
A source origin is not a backup folder with a dramatic name. It is the place the owner can trust when the working environment splits, disappears, or stops answering.
The encrypted baseline, delta journals, Git-shaped restore lane, owner custody, and daemon status become one stronger idea: recovery has to be controlled, readable, and separate from public product delivery.
The proof has to speak in artifacts: digests, byte counts, vault paths, restore commands, package manifests, entitlement checks, and receipts that a future operator can read without guessing what happened.
- Pulse: source custody, restore posture, owner control.
- Proof: The 17.3GB baseline matters because it gives the owner a known custody point. After that, every delta and receipt has a place in the recovery story.
- Boundary: The boundary is just as valuable as the artifact. Customer recovery, runtime packages, owner source custody, and private implementation source are not the same thing, and the public story gets stronger when it keeps those lanes separate.
The part that has to stay honest.
The boundary is just as valuable as the artifact. Customer recovery, runtime packages, owner source custody, and private implementation source are not the same thing, and the public story gets stronger when it keeps those lanes separate.
The useful move is to reduce the loss window, make restore evidence easier to read, and turn source safety into something a buyer can understand before the emergency hits.
The operator question I carry forward.
I want the reader to leave this piece with a sharper decision, not just a nicer impression. The question is not "does this sound impressive?" The question is whether the surface can help a real person act with more confidence after the click. That is where DevodeRator has to stay different from content noise.
The proof also has to survive a second read. A first read can be carried by energy, but a second read is where the claim either keeps its weight or starts to feel inflated. I care about that second read because a serious buyer, developer, or operator will come back to the page with sharper eyes after the first impression fades. The piece has to keep answering.
That means the public lane needs three things close together: the claim, the evidence shape, and the limit. The claim tells the reader what changed. The evidence shape tells them how the system knows. The limit tells them what is private, gated, unfinished, provider-bound, or waiting on a stronger receipt. When those three stay together, the public archive can be proud without getting sloppy.
I also want the reader to feel the operational consequence. If the lane is healthier, what becomes easier tomorrow? If the lane is weaker than it looked, what should be watched before money, trust, or reputation moves through it? That practical consequence keeps the writing tied to the business instead of floating above it.
For a founder, the useful question is what risk this lane reduces. For a developer, it is what architecture pressure the lane exposes. For a buyer, it is what proof can be followed without a private tour. For an operator, it is what next action becomes easier because the system exists. The article has to serve all four without pretending they are the same reader.
That is why I keep the proof and the boundary in the same room. Proof without boundary becomes hype. Boundary without proof becomes fear. The strong version says what happened, why it matters, where the public can inspect it, and where the private operating layer stays protected. That balance is the whole reason this archive can sell the 0S without turning the company inside out.
The next move is simple: keep making the lane more usable, keep the receipts close, keep the links loud enough to click, and keep the language alive enough that a serious reader remembers the point after the tab closes. That is the standard this archive has to carry now. ⚡
Sovereign source custody is valuable because it is disciplined, not because it is unlimited.
What changed.
The 17.3GB encrypted full-repo artifact is now treated as the baseline instead of something the daemon repeats every ten minutes. After that baseline exists, ordinary daemon wakes move through additive encrypted delta packs. If I add three lines in one file and twelve in another, the custody lane advances those changed files and tombstones instead of creating another huge full artifact.
That still was not enough by itself. A full artifact is the whole-workspace recovery shape, but I also needed a Git-shaped origin I could clone from a terminal when the job is normal source restoration. So the owner Git origin became a real service lane, not a note in my head.
This is an owner lane on purpose. A customer buying SkyeVault Agent should get their own workspace mirror and restore path. They should not inherit my private platform source, my operator material, or my internal source custody. Product trust depends on that boundary being visible.
- Full encrypted baseline:
MetrAIyux-0S-full-repo-20260529T213111Z.tar.zst.enc - Baseline size:
17,323,174,736bytes - Baseline SHA-256:
9ad319fd784a06ce458a6e04b73f67dd0c4f684ef31a36bef335a30e9da0b0e6 - Artifact receipt:
cdv_1cf38e5689280e988baf684e - Control receipt:
cdv_509b88a877b464c28b63d596 - Owner workspace:
metraiyux-0s-owner - Custody scope:
owner-private; client vault visibility is off. - Latest additive delta receipt during the correction:
cdv_397abe8f5ede4977141112fc - Earlier catch-up delta receipt:
cdv_ebe84f35641c71e201ffff51
The origin is cloneable.
I added the owner Git origin wrapper and proved it against this repo. The service runs locally at 127.0.0.1:8787, stores its private service token under ignored local state, seeds a bare Git repo under SkyeVault output, and exposes a clean clone URL without putting the token in the URL.
That clone path matters because serious recovery is not always "download an archive and sort it out later." Sometimes I need to move like a developer: clone, inspect, run connectivity checks, and keep going. SkyeVault now has that shape for the owner workspace while the encrypted full baseline still covers the broader all-bytes recovery case.
- Clone URL:
http://127.0.0.1:8787/metraiyux-0s-owner/MetrAIyux-0S.git - Token file:
.skyevault-out/git-remote/owner-git-origin.env - Storage root:
.skyevault-out/git-remote/storage - Seed receipt:
.skyevault-out/git-remote/owner-git-origin-sync.json - Proof receipt:
.skyevault-out/git-remote/owner-git-origin-proof.json - Remote
mainhead:6336a975e8702e50e06ed26da1cb026ba06290d6 - Proof result: fresh clone matched local
HEADandgit fsck --connectivity-onlypassed.
How the daemon is supposed to behave now.
The daemon wakes on the interval and checks the current repo state. If the full baseline already covers the baseline modes, it does not make another 17GB upload. It creates an encrypted delta pack for changed workspace state, syncs the owner Git origin for committed refs, writes receipts, and goes back to sleep.
That gives me two restore shapes. For Git history and normal terminal workflows, clone the owner origin. For the whole workspace, download the encrypted full baseline and apply the encrypted additive delta receipts. The point is not to replace Git with a random pile of folders. The point is to give Git parity plus all-bytes custody under my owner account.
The practical boundary stays honest: if the first baseline has not completed, there is no baseline to restore. If the workspace dies between daemon wakes, the recovery target is the last completed receipt. SkyeVault reduces the blast radius and proves custody; it does not pretend software can recover bytes it never captured.
The product value here is not only backup. It is sovereign source custody: owner account, shared gate, encrypted baseline, additive delta, cloneable origin, and receipts that say exactly what happened.