Frank
8af40c402b
Landing blocker for #61 and #63: the deployment checkout is 12 commits behind and `merge --ff-only` refuses while tracked paths are dirty. Discard is not available here (workspace policy: no `checkout`/`stash` on shared state), so the dirt is committed. - `agent/APPEND_SYSTEM.md`: the point-of-use / one-work-log / PR-link doctrine, already byte-identical to `origin/main` (`cmp` against the trunk blob: no difference). No new prose — the commit exists so the trunk merge can proceed. - `agent/config.yml` and `agent/managed-skills/**`: the machine-live tier the heartbeat owns (AGENTS.md § Live-sync tiers). `ALLOW_SECRETS=1` was used, deliberately and after auditing the staged diff by hand: the only credential-shaped strings in it are two copies of `AKIA0000000000000EXAMPLE` — the inert all-zero AWS example id — and they appear inside the two skill pages that teach that exact placeholder shape. This checkout is still running the pre-#61 hook; the merged gate (value-scoped placeholder filter, `71601f7`) exempts this value, so the refusal dies with this landing. No `--no-verify` was used: the gate ran and its verdict is recorded here. Refs #61
3.0 KiB
name, description
| name | description |
|---|---|
| gitea-token-from-http-credential-store | Extract the Dankclaw Gitea token from ~/.config/secrets/gitea (it is the URL password, not key=value lines) for API calls, and diagnose the silent empty-token trap that makes public-repo reads pass while writes fail. |
The Gitea credential store line on Frank's boxes is http (not https) with a percent-encoded port, and the token is the URL password — there are NO username=/password= lines:
http://dank:<40-char-token>@192.168.0.143%3a3000
Extraction that actually works
tok=$(sed -nE 's#^[a-z]+://[^:]+:([^@]+)@.*#\1#p' ~/.config/secrets/gitea | head -1)
curl -s -K <600-perm cfg file> http://192.168.0.143:3000/api/v1/<path>
git credential-store --file … fill answers EMPTY — do not debug it
Tried 2026-10-21 while opening dank/command-center PR #61: the obvious extraction
printf 'protocol=http\nhost=192.168.0.143\nport=3000\n\n' | git credential-store --file ~/.config/secrets/gitea fill
prints nothing, with no error. It is not a permissions problem and not a wrong path: the stored line encodes the port inside the host field (@192.168.0.143%3a3000), so a host=+port= query can never match it. Add path= or drop port= and it still answers empty. Read the file with sed (recipe above) and move on — the chain TOKEN=$(…) && [ -n "$TOKEN" ] && … fails silently at the test, which reads like a curl failure if the && hides it.
The silent-empty-token trap (bit 2026-10-21, cost a debug detour)
An awk -F= '/^username=/{...}' parse of this file yields tok="" silently — and reads still appear to work when the repo is public: dank/serverAppConfigs and dank/command-center return real issue/label data unauthenticated, so every census "passes" until the first write (issue comment, label, PR create/merge) fails with {"message":"token is always required"}-style errors or 404s (private repos 404 on an empty token — that is an auth problem, NOT a missing repo).
echo "tok len ${#tok}"(must be 40) before believing ANY API result — reads included.curl -s -K <600-perm file>carryingheader = "Authorization: token $tok"— never-Hon argv (/proc/<pid>/cmdlineis world-readable; this leaked an HF token once).- Prove auth once per session:
GET /api/v1/user→"login":"dank". - The temp
-Kconfig holds a live token:rm -fit in the same session that made the calls, and nevercatit.
Other notes
git credential fillfails headless here (could not read Username … terminal prompts disabled); read the store file directly instead.- Never print the token: mask when inspecting the file —
sed -E 's#(://[^:]+:)[^@]+@#\1REDACTED@#' ~/.config/secrets/gitea - Issue/PR numbers are per repo:
dank/dankvoice#8–#11 (refactor, hardening, AbortError fix, menu defects) are unrelated todank/command-center#8–#11 (SDLC, trunk-law). Read the body from the repo the work targets before referencing an issue in a commit message.