command-center/agent/managed-skills/command-center-bundle-lint-gate/SKILL.md

name, description

name	description
command-center-bundle-lint-gate	Before committing docs in dank/command-center, lint the real omp-docs bundle directly — the bats suite only lints fixtures, so a green suite is not proof.

The bundle lint gate (dank/command-center)

Adding or editing pages under omp-docs/? bats tests/ going green proves nothing about the pages you just wrote.

Why this exists

tests/kb-lint.bats exercises scripts/kb-lint.sh against mktemp -d fixtures ("conformant bundle passes", "missing frontmatter is reported", …). For years nothing in the suite pointed the linter at the shipped tree, so a page with no frontmatter, an index that stopped listing a file, or a broken relative link committed under a green suite. (Two tests appended 2026-10-20 now run both checkers against omp-docs/; verify they are still present before assuming the suite covers it — grep -n omp-docs tests/kb-lint.bats.)

The general law: a lint suite that tests only the linter does not lint your content. Check which one a suite runs before calling green a gate.

Gate a docs commit

cd <worktree>
bats tests/ ; grep -E '^1\.\.' /tmp/…          # suite (count, failures)
./scripts/kb-lint.sh omp-docs                  # want: kb-lint: 0 violation(s)
python3 scripts/kb-coverage.py omp-docs        # want: index-coverage: 0 issue(s)

kb-lint.sh <kb-dir> (default omp-docs) = OKF v0.1 conformance plus link integrity, so it is the check that absolute bundle links like /tools/gitea/client-access.md resolve. kb-coverage.py = every page listed by its directory index.md (repo doctrine: nothing may appear in a directory its index.md does not list).

OKF shape that passes: every concept page carries frontmatter with a type (type: reference + title/description/tags/timestamp/verified); index.md files carry no frontmatter; new pages get an entry in their directory index in the same commit, plus a dated entry in omp-docs/log.md (one entry = what changed + the durable lesson, a few lines, never a narrative).

Commit-message trap in this harness

A multi-line message written as a heredoc inside a chained bash command (git commit -q -F - <<'MSG' … && …) fails with pi-natives:command: syntax error at end of input. Write the message to /tmp/msg-<topic>.txt with the write tool and git commit -q -F /tmp/msg-<topic>.txt. Keep the && chain so a failed gate stops the commit — hooks (secret gate) stay armed, never --no-verify.

Land and reap

Merge is form-encoded do=merge&merge_style=no-ff and answers 200 with an empty body; never read that as ambiguous — verify by landing. Then git -C ~/.omp merge --ff-only origin/main (the checkout is the deployment; dirty agent/memories/, agent/config.yml, APPEND_SYSTEM.md are machine-tier live state and do not block an ff whose diff misses them), fast-forward the session's wt/* scratch branch the same way, then git worktree remove <build-wt> and git branch -d <type>/<issue>-<slug> (-d succeeding is itself proof of merge).

Stray files whose names start with - (e.g. -c, -es — vim takes a --startuptime flag name as the output filename) show as untracked dirt: mv ./-c .AGENTTRASH/<date>-<meaning>.log, never rm.