bug(setup paseo): skill bridge can never reach a clean --check against Paseo desktop 0.4.0 (hardcoded allowlist + missing ~/.agents/skills)

[lotgood]

Summary

On a machine where Paseo is installed as the desktop app (Paseo.app 0.4.0), gjc setup paseo --check can never reach a clean verdict. The skill bridge assumes (a) a hardcoded skill-name allowlist and (b) ~/.agents/skills as the only source directory. Neither holds for an app install, so every reachable state reports drift and exits 1.

The ACP provider itself works — this is only the skills bridge and its --check verdict.

Environment

• gjc/0.14.0 (compiled binary, ~/.local/bin/gjc)
• macOS 27.0.0, arm64
• Paseo desktop app 0.4.0 (/Applications/Paseo.app), daemon 0.4.0; no paseo CLI on PATH
• ~/.paseo/config.json (app config), provider agents.providers.gjc installed by gjc setup paseo

What GJC expects vs. what Paseo 0.4.0 ships

GJC's allowlist is hardcoded in the binary:

$ strings -a ~/.local/bin/gjc | grep -o 'eq_=\["paseo".*'
eq_=["paseo","paseo-advisor","paseo-committee","paseo-handoff","paseo-loop"]

The installed Paseo app ships its skills inside the bundle, and the set does not match:

$ ls /Applications/Paseo.app/Contents/Resources/skills
paseo  paseo-advisor  paseo-committee  paseo-handoff  paseo-help

$ ls ~/.agents/skills
ls: /Users/<me>/.agents/skills: No such file or directory

• paseo-loop — in GJC's allowlist, not shipped by Paseo 0.4.0
• paseo-help — shipped by Paseo 0.4.0, not in GJC's allowlist
• ~/.agents/skills — GJC's only bridge source, does not exist for a desktop-app install

Reproduction: every reachable state is drift

1. Fresh app install (~/.agents/skills absent) — gjc setup paseo still creates 5 symlinks into a directory that does not exist:

$ gjc setup paseo
✓ GJC registered with Paseo
  updated ~/.gjc/agent/paseo-skills
  updated config.yml skills.customDirectories

$ gjc setup paseo --check
✘ Paseo setup has drifted
  orphan-skill: ~/.gjc/agent/paseo-skills/paseo-loop -- bridge symlink target no longer exists
  orphan-skill: ~/.gjc/agent/paseo-skills/paseo -- bridge symlink target no longer exists
  orphan-skill: ~/.gjc/agent/paseo-skills/paseo-committee -- bridge symlink target no longer exists
  orphan-skill: ~/.gjc/agent/paseo-skills/paseo-handoff -- bridge symlink target no longer exists
  orphan-skill: ~/.gjc/agent/paseo-skills/paseo-advisor -- bridge symlink target no longer exists
# exit 1

2. Provide the source directory from the app bundle (~/.agents/skills/<name> -> /Applications/Paseo.app/Contents/Resources/skills/<name> for all 5 shipped skills):

$ gjc setup paseo --check
✘ Paseo setup has drifted
  orphan-skill: ~/.gjc/agent/paseo-skills/paseo-loop -- bridge symlink target no longer exists
  unlinked-skill: ~/.agents/skills/paseo-help -- Paseo skill is outside GJC's locked bridge allowlist
# exit 1

3. Delete the un-satisfiable paseo-loop link — the check flips to the opposite complaint:

$ rm ~/.gjc/agent/paseo-skills/paseo-loop && gjc setup paseo --check
✘ Paseo setup has drifted
  missing-bridge-link: ~/.gjc/agent/paseo-skills/paseo-loop -- bridge symlink is missing
  unlinked-skill: ~/.agents/skills/paseo-help -- Paseo skill is outside GJC's locked bridge allowlist
# exit 1

~/.gjc/agent/paseo/provenance.json pins the same list, so re-running gjc setup paseo restores the dangling paseo-loop link:

{
  "bridgePath": "/Users/<me>/.gjc/agent/paseo-skills",
  "bridgeEntries": ["paseo", "paseo-advisor", "paseo-committee", "paseo-handoff", "paseo-loop"],
  "bridgeDirCreated": false
}

There is no --no-skills / bridge-only opt-out; the only escape is gjc setup paseo --remove, which also removes the provider registration.

Expected

gjc setup paseo --check should be able to report pass on a supported, unmodified Paseo installation.

Suggested fix

1. Derive bridge entries from what the source actually contains instead of a compiled-in name list — a Paseo release that adds or drops an orchestration skill must not turn --check permanently red.
2. Discover the desktop app's skill directory. For app installs the skills live at /Applications/Paseo.app/Contents/Resources/skills ($PASEO_APP/Contents/Resources/skills), not ~/.agents/skills. Today GJC silently creates dangling symlinks into a non-existent directory, which is worse than skipping the bridge.
3. Do not create symlinks whose target does not exist — if the source is missing, skip the bridge and say so once.
4. Downgrade unlinked-skill to informational. A Paseo skill that GJC does not bridge is not drift in GJC's own installation; the allowlist should not make a newer Paseo version look broken.

Impact

Cosmetic but misleading: after a fully successful gjc setup paseo the verification command a user is told to run reports failure with exit code 1, and there is no action that makes it pass. It also makes --check useless for detecting real drift on these machines.

[Yeachan-Heo]

Fix published: #4644 (fix/issue-4638-paseo-bridge → dev, exact head 4981a92170bde45f881588729fa5356b8aae2499, rebased onto current dev 6696988b6d).

Every failure state from this report was reproduced in isolated temp fixtures before the change (all drift, exit 1, no reachable clean verdict) and verified corrected after:

Scenario from the report	Before	After
Desktop app install, ~/.agents/skills absent	5 dangling links + orphan-skill ×5, exit 1	bundle skills bridged, --check = pass
Shipped set paseo-help vs allowlisted paseo-loop	orphan-skill + unlinked-skill, exit 1	no unlinked-skill class; re-run converges (prunes paseo-loop, links paseo-help), then pass
No source directory at all (Paseo uninstalled)	dangling links silently created	bridge skipped, nothing created, one missing-skills-directory reason
Deleting an un-satisfiable link by hand	check flips to the opposite complaint	deleting a provenanced link is real drift; deleting an unbridged skill is not reported
--remove	allowlist-filtered, restores nothing useful	provenance-gated; cleans the bridge even after Paseo itself is uninstalled; claude entry and the daemon credential survive

Bridge names are now derived from the source directory's actual contents through a bounded discovery seam (~/.agents/skills → Paseo.app Contents/Resources/skills under /Applications/~/Applications → PASEO_SKILLS_DIR), never hardcoded, and no symlink is ever created whose target is missing.

Verification: 87 setup-paseo tests (+105 with setup-cli), package biome+tsc, check:ts, ci:test:smoke, and the check-visible-definitions / verify-g002-gates / rebrand-inventory --strict / default-gjc-definitions gates — all green at the posted head.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Fresh full-census reconciliation (2026-08-18T10:02Z) — supersedes the earlier pinned head.

Linkage: PR #4644 owns this fix. fix/issue-4638-paseo-bridge → dev, exact head af4793684f6b620bcc53c2490b7c6a58942208a9 (base dev @ 416201eb5e). The head recorded in the earlier comment (4981a921) was superseded by two authorized force-pushes (8e7ddf5f → c5d80112 → af479368) — all pinned review/CI evidence at 4981a921 is stale.

Current exact-head state (af4793684f):

Dimension	State
PR	OPEN, not draft, mergeable: true, mergeable_state: unstable
Review	CHANGES_REQUESTED — @probepark 2026-08-18T07:02:04Z at this exact head, merge blocked
CI	All product/content checks green (setup-paseo tests, package check, ts-build, cli-smoke, native-build, evidence producer, gjc-state-gates, virtual integration); only PR contract bootstrap + Validate exact-head PR contract red — by-design needs-human gates that require an authenticated non-author approving review at this head

Open review findings at af479368 (unresolved, merge-blocking):

1. major — setup-time pruning treats a recorded name as ownership; it must apply the same exact-target verification --remove already has (target equality against the ledger-recorded bridgeSourceDir), and legacy adoption must be gated on the ledger actually being legacy.
2. major — PASEO_SKILLS_DIR is read from process.env, which includes an untrusted repo's .env; global setup must not persist repo-controlled prompt skills.
3. major — bridge mutation commits before provenance is durable; a failed ledger write leaves unowned live links that retry classifies as noops.
4. minor — bridgeDirCreated is not durable across convergence runs, so --remove can strand GJC's own empty bridge dir.
5. coverage — four unpinned findings: no retargeted ledger-recorded-link test, no .env injection test, no failed-ledger-write fault-injection, no create → source-change → reinstall → remove sequence.

Live dev check (independent): origin/dev still ships the compiled-in INSTALL_SKILL_NAMES = ["paseo","paseo-advisor","paseo-committee","paseo-handoff","paseo-loop"] allowlist with ~/.agents/skills as the sole bridge source — the reported failure modes are real on every unmerged dev build. Dev baseline reproduced clean in an isolated worktree (73/73 setup-paseo tests pass on dev source), and the census found no second fixing lane (prior Paseo PRs #4417/#4432/#4366 are unrelated history).

Disposition: issue stays open as evidence/closure owner. The blocking path to the clean verdict this report asks for runs through the exact-head findings above: an authorized non-author review flipping to approval at af4793684f (or a fix-forward push + fresh review), then dev merge. This issue closes only when the covering PR is dev-merged, with exact merged evidence posted here. No duplicate implementation will be opened from this lane.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]