Sync & Info-Access Audit

cortextOS / SiteSmith agency · 2026-06-11 · read-only diagnostic by the Analyst agent · nothing was changed — every fix below is a proposal awaiting your review

The one-line answer

Your data is not lost and your live systems are healthy. There is exactly one real problem: the offsite backup of your agent "brain" hasn't run since June 5 (6 days), because the backup automation is both unscheduled and silently failing.

In plain English

What's fine: Git is fully in sync (nothing unpushed, nothing stale). Your knowledge base (the thing agents search to "pull info") returns correct results. Nothing is silently broken on the read side.
What's broken: Every few days, a backup script is supposed to copy the whole agent brain into a private GitHub repo so it's safe off your laptop. That script (a) was never put on a schedule, and (b) when it does run, it stops itself on purpose because it spots secret-looking files in the batch. So no automated backup is currently getting through — the last successful backup of any kind was a manual one you ran on June 5.
Why it matters: 6 days of agent memory, goals, and work currently live on one disk with no off-machine copy (unless Google Drive happens to mirror that folder — see the one thing I need you to confirm).
Is the fix safe? Yes. It's: fix what the script copies so secrets/junk don't enter the batch, put it on a daily schedule, and run one backup to close the gap. No live system changes; nothing destructive.

How everything is wired (so the rest makes sense)

Your org data physically exists in one place only. The "mirror" in the Obsidian vault is a Windows junction (a pointer), not a second copy — which is why it always looks identical to the live files.

LIVE DATA (one physical copy, gitignored in the public fork) C:\...\cortextos\orgs\sitesmith-agency\ | | (Windows directory JUNCTION — same bytes, not a copy) v C:\...\Obsidian\AIAgency\...\cortex-os\sitesmith-agency\ | | git add + commit + push <-- THE OFFSITE BACKUP STEP v GitHub: sukelevensai/aiagency (PRIVATE) last snapshot: 2026-06-05

The public cortextos fork deliberately gitignores all org data (so nothing leaks publicly). That means the private aiagency repo is the only git path that backs your data off the machine.

Findings

High* Offsite backup is 6 days stale and silently broken

Evidence

Last backup commit touching the brain mirror: 5c1caab7e, 2026-06-05 (manual, by you). None since = 6 days, zero automated snapshots.
The backup script's header says "Run by: analyst daily cron" — but no such cron exists (verified against all 15 scheduled crons; none reference the backup).
The script's log contains exactly one line: [2026-06-05T02:09Z] ABORT: SECRET-SCAN FAIL in 82 file(s); nothing committed. It correctly fail-closes when the copy batch contains secret-looking files — and the batch did: a mix of (1) genuine secret files the copy filter missed (agent .env files, an .env backup variant, OAuth/client-secret JSON), (2) a worker project's node_modules (binaries, type defs), and (3) false positives — docs that merely mention tokens (the gap backlog, the knowledge base, an agent skill doc).
Net result: the automated path is not currently completing, and no automated backup commit appears in recent history. The last successful backup was the manual June 5 commit. (I can't rule out an older successful run before the current setup — but nothing has landed off-machine in the last 6 days, which is what matters.)

Severity caveat (please confirm)

Google Drive for Desktop is running with folder mirroring on. If it mirrors the Obsidian vault (or the cortextos folder), you already have a continuous secondary backup and this drops to Medium. OneDrive does not cover these paths. I can't read the Drive config from here — only you know if that folder is on Drive. One nuance: folder-mirroring is continuous, not versioned — a deletion propagates and there's no point-in-time history to roll back to, which is exactly what the git snapshots give you. So it's a safety net, not a full replacement.

Proposed fix (not applied)

Tighten the copy exclusions so secrets & node_modules never enter the batch (add .env.bak*, *.bom, *client_secret*, *oauth*; exclude node_modules at every depth).
Rather than loosening the secret scan, switch it to an explicit denylist + a narrow include-list (only the file types worth backing up) — so a doc that later contains a real pasted secret still can't slip through. Then do one dry-run / staged-diff review before the first scheduled run.
Add the daily backup cron that was always intended.
After the exclusion fix, run one backup now to close the 6-day gap.

Keep as-is: the fail-closed scan is the only thing that stopped those secret files from being pushed to GitHub. It did its job — don't weaken it.

OK Git sync & push — all healthy

Repo	State vs its remote	Note
cortextos	`0 / 0` vs origin	In sync, all commits pushed
AIAgency vault	`0 / 0` vs origin	Committed work fully pushed
client site	clean	—
client vault	`0 / 0`	4 in-flight handoff files (normal)

No repo is behind its remote, so "reading stale info from an un-pulled vault" is ruled out. (Minor: cortextos main tracks the upstream fork, not your origin — a footgun if you ever run a bare git push on main. Low priority; one-line fix to retarget it.)

OK Knowledge base (the "pull info" engine) — working

A live query for a known term returned 10 relevant, correctly-ranked results; all collections are populated (the shared org collection alone holds ~6,930 documents). The known "silent-empty-on-failure" bug did not occur today. Recommend keeping the planned hardening (make a backend failure look different from "no results") as low-priority insurance.

Low / latent Search-tool blind spot for org data

Evidence

A plain text search run from the repo root returns "No files found" for text that does exist in the org files — because the entire org folder is gitignored and the search tool skips gitignored paths. Pointing the search directly at the org folder finds it instantly.

Honest caveat: this is a real footgun, but I did not see it actually cause a failure today. It's the most likely explanation if a "couldn't find info" moment came from a top-level search. Mitigation: pull org info via the knowledge base (works), or always search the org folder by explicit path.

By design Not bugs — leave these alone

Secret files blocked from reads, org data gitignored in the public fork, and the private repo kept separate — all deliberate security boundaries.
cortextos being "89 ahead" of the upstream project is the intended state of your fork.

So — were you "having trouble pulling info"?

Based on today's evidence: no read-side failure reproduced. The knowledge base answers, git is synced, nothing is stale. The one genuine "something's not working" is on the write/backup side, not the read side.

If you had a specific moment where you (or an agent) tried to pull something and got nothing — tell me the exact thing, and I'll reproduce it. The search blind-spot above is my prime suspect for that kind of moment.

Proposed plan (in order, nothing done yet)

Confirm whether Google Drive mirrors the vault folder (decides whether the backup gap is High or Medium).
Fix the backup script's exclusions + secret-scan allowlist.
Schedule the daily backup cron.
Run one backup to close the 6-day gap.
Optional low-priority: retarget cortextos main to your origin; add KB silent-failure hardening; document the search-by-explicit-path habit.

Say the word and I'll do these one at a time, showing you each change before it runs.

Read-only audit. No files, configs, branches, or remotes were modified. Diagnostics: git status / rev-list / fetch (read-only), fsutil reparsepoint, knowledge-base query, and the backup script's own log. Secret values were never read or included; file references are generalized.