Dedicated credential qualification: NO-GO (18 October 2026)
The dedicated secure binding is now present and reports ready. Every qualification request in this run used VM_BACKUP_GITHUB_TOKEN. The integration-managed GH_TOKEN was not substituted. No backup architecture or application code was changed.
Actual live results
| Check | Result |
|---|---|
| Private backup repository read, api.github.com | 200; private=true, read/write reported |
| New disposable release creation, api.github.com | 201 |
| First small age-encrypted asset POST, uploads.github.com | 404, one attempt |
| Uploaded assets / committed checkpoints | 0 / 0, verified by read-only queries |
| Destructive recovery and incremental checkpoint | Blocked by upload failure |
| Trusted-machine comparison | Unavailable: no independent trusted machine attached |
| Secure HF credential | Absent; private staging remains unqualified |
Upload request ID: FE93:319F8B:36F88A:4FB435:6AD3F6B8.
Disposable namespace: test-recovery-20261017-745d0278 (the harness uses UTC host
clock naming; this qualification report uses the client Berlin date).
The new release is uncommitted and empty; no pre-existing release or checkpoint
was altered or deleted. No recurring workflow or production setting changed.
The client used GitHub's returned upload_url, validated its destination and attached the dedicated authorization header. A GitHub response/request ID proves an HTTPS service response, not which credential the proxy ultimately forwarded. The earlier missing-binding problem is resolved. The former integration-token 401 is not reused as evidence about this token. The new 404 may conceal a private resource/permission rejection or reflect credential propagation differences between hosts. Scope versus injection/proxy attribution remains undetermined. API release creation proves a successful write through that route; it does not prove that the same upstream identity was used on the upload route.
Evidence:
- Dedicated API probe
- Current live upload/recovery attempt
- Qualification decision
- Prior blocked attempt retained
Exact next step: trusted-machine comparison
Use an independently trusted machine outside this managed proxy, provision the same permitted dedicated credential there from its secure store, and check out application branch feature/video-rag-mentor-v2. Do not export a proxy placeholder, copy integration-managed credentials, paste credentials into chat, disable TLS, or bypass this managed environment's network controls.
With Python 3.12+, uv, FFmpeg and age/age-keygen available, run from the checkout:
if [ -z "${VM_BACKUP_GITHUB_TOKEN:-}" ]; then
echo 'Dedicated backup credential required' >&2
exit 2
fi
uv run --frozen --group dev python tests/live_github_recovery.py
The guard prevents the harness's legacy GH_TOKEN fallback. The drill creates a new disposable namespace and never deletes existing remote releases. Successful upload continues to readback, committed checkpoints, unchanged incremental dedup and full recovery after destroying local source/staging state, with fresh-process Library, Search, config/index and media checks. Compare sanitized evidence JSON only.
- Outside succeeds while managed fails: managed credential propagation or proxy behavior is implicated; header stripping versus rewriting still needs trusted proxy observability. Do not weaken or work around its security controls.
- Outside also fails: review the credential's resource owner, selected private repository JsonLord/visual-mentor-backups, Contents read/write, Metadata read, expiry and any applicable organization authorization. Matching failures alone do not conclusively distinguish every GitHub policy/resource issue.
Private staging package remains prepared at deploy/hf-staging/README.md. Secure HF credentials are still absent, and the existing public Space remains unchanged. NO-GO for first private staging deployment until a dedicated-token asset upload and complete GitHub-only recovery succeed and private staging access is qualified.
Standalone trusted-machine diagnostic prepared (18 October 2026)
The independent standard-library probe is qualify_github_release.py. It needs only Python and age/age-keygen; it imports no application code, reads only VM_BACKUP_GITHUB_TOKEN, creates one unique test release, uses the returned validated upload_url, and verifies encrypted asset SHA-256 by readback. Permanent HTTP errors stop immediately without retries. Its new evidence filename is unique and existing files are refused. All prior evidence above has been preserved.
Exact Linux and Windows instructions include a gated full-recovery invocation after upload GO and archival of the existing recovery report before the unchanged harness runs. Windows execution and an independent trusted machine are not available in this managed Linux session.
Four standalone stdlib unit tests passed: mocked successful readback/hash, removal of authorization on signed redirects, no fallback to GH_TOKEN, evidence-overwrite refusal, destination validation and permanent-rejection stopping. The managed live probe again created a new synthetic test release successfully, but its first asset upload returned 404. No asset ID/readback or complete recovery success is claimed. The full destructive test was not run because its upload prerequisite did not pass.
New evidence: standalone probe JSON. Managed upload: NO-GO; full GitHub recovery: not run; first private staging: NO-GO. No backup code was refactored, deployment performed, workflow activated, or existing release/checkpoint modified or deleted. The next action is to run this standalone script on the trusted laptop/Debian server with the same securely provisioned token and return its sanitized JSON, never the token or a proxy placeholder.