P1 · Unraid media & ownership conventions (doc + PUID landmine) #7

New issue

Open

opened 2026-07-11 19:59:53 -05:00 by adam · 0 comments

adam commented

2026-07-11 19:59:53 -05:00

Owner

Priority: P2 · Size: M · Depends on: none

Goal

Every lab credential has a runbook (skill), and no skill references a fragile 1Password display-name path.

Why (from the 2026-07-11 session)

Two friction points, both about credential access:

op://foundry/dockhand/api_key existed in the vault with no skill — I had to discover the base URL, that auth is Bearer (not X-API-Key/token), the endpoints, and the ?env=1 gotcha by trial-and-error (~6 blind probes, and nearly reported "Dockhand has 0 stacks" because /api/stacks returns [] without ?env=).
op://foundry/Forgejo Adam Token/credential failed mid-session ("isn't an item in the vault") because the item was renamed; I fell back to op://foundry/forgejo/api_token. Skills that hard-reference display-name paths silently rot.

Steps

Enumerate foundry-vault items/credentials (respecting feedback_op_service_token — always use the service-token pattern; reads only, writes need confirmation per feedback_1password_write).
Build a credential → skill coverage table; identify gaps.
For each gap, write a minimal per-surface skill (or fold into an existing one).
Audit ALL .claude/skills/** for op:// references using display-name paths; repoint to stable kebab/slug paths.
Document the convention in .claude/skills/README.md: "new credential ⇒ ship a skill + reference it by a stable op:// path."

Acceptance

A credential→skill coverage table exists; every skill op:// reference uses a stable path; the convention is written down.

Resources

Skills: op-secrets, forgejo-api. Memory: feedback_1password_naming_collisions, feedback_op_service_token, feedback_1password_write.

**Priority:** P2 · **Size:** M · **Depends on:** none ## Goal Every lab credential has a runbook (skill), and no skill references a fragile 1Password display-name path. ## Why (from the 2026-07-11 session) Two friction points, both about credential access: 1. `op://foundry/dockhand/api_key` existed in the vault with **no skill** — I had to discover the base URL, that auth is **Bearer** (not `X-API-Key`/`token`), the endpoints, and the `?env=1` gotcha by trial-and-error (~6 blind probes, and nearly reported "Dockhand has 0 stacks" because `/api/stacks` returns `[]` without `?env=`). 2. `op://foundry/Forgejo Adam Token/credential` **failed** mid-session ("isn't an item in the vault") because the item was renamed; I fell back to `op://foundry/forgejo/api_token`. Skills that hard-reference display-name paths silently rot. ## Steps - Enumerate foundry-vault items/credentials (respecting `feedback_op_service_token` — always use the service-token pattern; reads only, writes need confirmation per `feedback_1password_write`). - Build a credential → skill coverage table; identify gaps. - For each gap, write a minimal per-surface skill (or fold into an existing one). - Audit ALL `.claude/skills/**` for `op://` references using display-name paths; repoint to stable kebab/slug paths. - Document the convention in `.claude/skills/README.md`: "new credential ⇒ ship a skill + reference it by a stable `op://` path." ## Acceptance A credential→skill coverage table exists; every skill `op://` reference uses a stable path; the convention is written down. ## Resources Skills: `op-secrets`, `forgejo-api`. Memory: `feedback_1password_naming_collisions`, `feedback_op_service_token`, `feedback_1password_write`.

adam added the

lab-honing

label

2026-07-11 19:59:53 -05:00

No labels

lab-honing

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

adam/foundry#7

No description provided.

Rows
Columns