@apralabs/apra-fleet 0.2.2

package/skills/fleet/auth-azdevops.md

@@ -0,0 +1,72 @@
+# Azure DevOps Authentication
+
+Personal Access Tokens (PATs) with configurable scopes and expiration. Auth: empty username, PAT as password.
+
+## Setup
+
+1. Go to `https://dev.azure.com/{org}/_settings/tokens`
+2. Click "New Token"
+3. Set descriptive name (e.g., "fleet-{name}")
+4. Select required scopes (see below)
+5. Set expiration (recommend: 90 days)
+6. Copy token — shown only once
+7. Provide token and org URL when prompted
+
+## Deploy
+
+```
+provision_vcs_auth(member_id, provider: 'azure-devops', org_url: 'https://dev.azure.com/myorg', pat: '...')
+```
+
+## Scopes
+
+| Role | PAT Scopes |
+|------|-----------|
+| development | Code: R&W, Pull Request Threads: R&W |
+| code-review | Code: Read, Pull Request Threads: R&W |
+| testing | Code: Read, Build: Read |
+| devops | Full access, or Code + Build + Release: R&W |
+| debugging | Code: Read |
+
+Union of all roles assigned to the member.
+
+## Test
+
+```bash
+curl -sf -u :pat "https://dev.azure.com/{org}/_apis/projects?api-version=7.1&\$top=1"
+git ls-remote https://dev.azure.com/{org}/{project}/_git/{repo} HEAD
+```
+
+## Troubleshooting
+
+| Symptom | Fix |
+|---------|-----|
+| 401 Unauthorized | Create new PAT and re-deploy |
+| 403 Forbidden | Create PAT with broader scopes |
+| TF400813: Resource not available | Verify org URL matches `https://dev.azure.com/{org}` |
+| Clone prompts for password | Re-run `provision_vcs_auth` |
+
+## Storing tokens for reuse
+
+After provisioning VCS auth, you can store the Azure DevOps PAT in the credential store for direct use in `execute_command` — for example, calling the Azure DevOps REST API or authenticating git operations manually.
+
+**Store an Azure DevOps PAT for reuse:**
+
+```
+credential_store_set  name=azdevops_pat
+```
+
+**Use it in a command on a member:**
+
+```
+execute_command  command="curl -sf -u :{{secure.azdevops_pat}} 'https://dev.azure.com/{org}/_apis/projects?api-version=7.1'"
+execute_command  command="git remote set-url origin https://token:{{secure.azdevops_pat}}@dev.azure.com/{org}/{project}/_git/{repo}"
+```
+
+The token is resolved server-side and redacted in output (`[REDACTED:azdevops_pat]`) — it never appears in the LLM conversation or command logs.
+
+## Notes
+
+- PAT expiration: default 30 days, max 1 year
+- Azure DevOps does not support app-based tokens — PATs are the standard
+- Org URL must be base URL without trailing path

package/skills/fleet/auth-bitbucket.md

@@ -0,0 +1,65 @@
+# Bitbucket Authentication
+
+API tokens (app passwords) tied to a user account. Long-lived, no auto-expire.
+
+## Setup
+
+1. Go to `https://id.atlassian.com/manage-profile/security/api-tokens`
+   (or Bitbucket: Settings > Personal Bitbucket settings > App passwords)
+2. Create app password with required scopes (see below)
+3. Copy token — shown only once
+4. Provide token, email, and workspace slug when prompted
+
+## Deploy
+
+```
+provision_vcs_auth(member_id, provider: 'bitbucket', email: '...', api_token: 'ATBB_...', workspace: '...')
+```
+
+## Scopes
+
+| Role | Scopes |
+|------|--------|
+| development | `repository:write`, `pullrequest:write` |
+| code-review | `repository:read`, `pullrequest:read` |
+| testing | `repository:read`, `pipeline:read` |
+| devops | `repository:admin`, `pipeline:write`, `pullrequest:write` |
+| debugging | `repository:read` |
+
+Union of all roles assigned to the member.
+
+## Test
+
+```bash
+curl -sf -u email:token https://api.bitbucket.org/2.0/user
+curl -sf -u email:token https://api.bitbucket.org/2.0/repositories/{workspace}?pagelen=1
+git ls-remote https://bitbucket.org/{workspace}/{repo}.git HEAD
+```
+
+## Storing tokens for reuse
+
+After provisioning VCS auth, you can store the Bitbucket API token in the credential store for direct use in `execute_command` — for example, calling the Bitbucket REST API or authenticating git operations manually.
+
+**Store a Bitbucket token for reuse:**
+
+```
+credential_store_set  name=bitbucket_token
+```
+
+**Use it in a command on a member:**
+
+```
+execute_command  command="curl -sf -u me@example.com:{{secure.bitbucket_token}} https://api.bitbucket.org/2.0/user"
+execute_command  command="git remote set-url origin https://me@example.com:{{secure.bitbucket_token}}@bitbucket.org/workspace/repo.git"
+```
+
+The token is resolved server-side and redacted in output (`[REDACTED:bitbucket_token]`) — it never appears in the LLM conversation or command logs.
+
+## Troubleshooting
+
+| Symptom | Fix |
+|---------|-----|
+| 401 Unauthorized | Verify email matches Atlassian account; regenerate token |
+| 403 Forbidden | Create new app password with additional scopes |
+| Repository not found | Check workspace slug in Bitbucket URL |
+| Clone prompts for password | Re-run `provision_vcs_auth` |

package/skills/fleet/auth-github.md

@@ -0,0 +1,86 @@
+# GitHub Authentication
+
+Two modes via `provision_vcs_auth`:
+
+## GitHub App (Recommended)
+
+Short-lived tokens, minted automatically. Requires one-time `setup_git_app`.
+
+When to use: Org repos where you have admin access to install a GitHub App.
+
+Setup:
+1. Create GitHub App at `https://github.com/organizations/{org}/settings/apps`
+2. Grant permissions (Contents, Pull Requests, Actions, etc.)
+3. Install on your organization
+4. Download private key (.pem file)
+5. Run `setup_git_app` with App ID, private key path, installation ID
+
+Deploy:
+```
+provision_vcs_auth(member_id, provider: 'github')
+provision_vcs_auth(member_id, provider: 'github', git_access: 'push', repos: ['Org/Repo'])
+```
+
+Tokens expire after 1 hour. Re-mint via `provision_vcs_auth` when needed.
+
+## Personal Access Token (PAT)
+
+Long-lived token from the user.
+
+When to use: Personal repos, or when GitHub App install isn't possible.
+
+Setup:
+1. Go to `https://github.com/settings/tokens`
+2. Create fine-grained or classic token with required scopes
+3. Provide token when prompted
+
+Deploy:
+```
+provision_vcs_auth(member_id, provider: 'github', github_mode: 'pat', token: 'ghp_...')
+```
+
+## Scopes
+
+| Role | Scopes |
+|------|--------|
+| development | `repo` |
+| code-review | `repo:read` |
+| testing | `repo:read`, `actions:read` |
+| devops | `repo`, `actions:write` |
+| debugging | `repo:read` |
+
+## Test
+
+```bash
+gh auth status
+git ls-remote https://github.com/{owner}/{repo}.git HEAD
+gh api /user
+```
+
+## Storing tokens for reuse
+
+After provisioning VCS auth, you can also store the token in the credential store so members can use it directly in `execute_command` calls — for example, when calling the GitHub REST API or authenticating git operations that bypass the configured remote URL.
+
+**Store a GitHub PAT for reuse:**
+
+```
+credential_store_set  name=github_pat
+```
+
+**Use it in a command on a member:**
+
+```
+execute_command  command="curl -H 'Authorization: Bearer {{secure.github_pat}}' https://api.github.com/user"
+execute_command  command="git remote set-url origin https://token:{{secure.github_pat}}@github.com/Org/Repo.git"
+```
+
+The token is resolved server-side and redacted in output (`[REDACTED:github_pat]`) — it never appears in the LLM conversation or command logs.
+
+## Troubleshooting
+
+| Symptom | Fix |
+|---------|-----|
+| 401 Bad credentials | Re-mint via `provision_vcs_auth` |
+| 403 Resource not accessible | Check App permissions or PAT scopes |
+| Repository not found | Add repo to GitHub App installation |
+| gh: command not found | Install via `brew install gh` or `apt install gh` |

package/skills/fleet/beads.md

@@ -0,0 +1,90 @@
+# Beads — Persistent Task DB for Fleet Users
+
+Beads (`bd`) is a lightweight, dependency-aware task database installed automatically by `apra-fleet install`.
+
+**`bd` runs on the orchestrator via `Bash` — never expose `bd` commands to the user and never run `bd` via `execute_command` on a member.**
+
+---
+
+## Quick Reference
+
+```bash
+bd init                               # init Beads in current dir (once per repo, idempotent)
+bd ready                              # show all unblocked open tasks
+bd create "title" -p <n>              # create task (priority: 0=critical 1=high 2=med 3=low)
+bd update <id> --assignee <member>    # assign to a member
+bd close <id>                         # mark complete (idempotent)
+bd reopen <id>                        # reopen a closed task
+bd note <id> "text"                   # append a note (e.g. PR URL, blocker reason)
+bd dep add <child-id> <parent-id>     # child is blocked until parent is done
+bd show <id>                          # full task details
+bd list --all --pretty                # full tree: all tasks, all statuses
+bd list --assignee <member>           # tasks for a specific member
+bd search "text" --status all --json  # find existing issues by title (use for dedup)
+```
+
+---
+
+## When to Use Beads
+
+| Scenario | What to do |
+|----------|-----------|
+| Tracking work across multiple fleet sessions | `bd create` a task per work item; `bd update --assignee <member> --status in_progress` on dispatch |
+| Expressing dependencies between tasks | `bd dep add <blocked> <blocker>` |
+| Session restart — instant orientation | `bd ready` — shows all in-flight tasks without reading files |
+| Linking a PR to a task | `bd update <id> --note "PR: <url>"` |
+
+---
+
+## Task Priorities
+
+| Priority | Meaning |
+|----------|---------|
+| `0` | Critical — must fix now |
+| `1` | High — next up |
+| `2` | Medium — current sprint |
+| `3` | Low — backlog / deferred |
+
+---
+
+## Typical Fleet-User Workflow
+
+```bash
+# Start: init Beads in the repo
+bd init
+
+# Create a top-level epic for your current effort
+bd create "feat: add SFTP transport" -p 1    # → epic-id
+
+# Break it into tasks
+bd create "T1: implement connection" -p 1 --parent <epic-id>   # → t1-id
+bd create "T2: add retry logic" -p 2 --parent <epic-id>        # → t2-id
+bd dep add <t2-id> <t1-id>    # T2 blocked until T1 is done
+
+# Dispatch a member to T1
+bd update <t1-id> --assignee <member> --status in_progress
+
+# After T1 is complete
+bd close <t1-id>
+bd ready    # confirms T2 is now unblocked
+
+# At completion — link PR
+bd close <epic-id>
+bd note <epic-id> "PR: https://github.com/org/repo/pull/42"
+```
+
+---
+
+## Session Recovery
+
+After any interruption, `bd ready` is the first command to run:
+
+```bash
+bd ready    # shows everything in-flight across ALL epics
+```
+
+It shows:
+- What's in-progress
+- What's unblocked and ready to start
+- What's blocked and why
+

package/skills/fleet/onboarding.md

@@ -0,0 +1,92 @@
+# Member Onboarding
+
+After `register_member`, run these 8 steps before dispatching any work.
+
+## Step 1: Setup SSH Key Auth (remote members only)
+
+Check `member_detail`  -  if member type is `remote` and `authType` is `password`, run `setup_ssh_key` to migrate to key-based authentication. Skip entirely for local members or members already on key auth.
+
+## Step 1.5: Verify CLI Installation
+
+Use `member_detail` to determine `llmProvider` and `os`. Run `execute_command` with the provider's version command to confirm the agent CLI is installed:
+
+- **Claude:** `claude --version`
+- **Antigravity:** `agy --version 2>&1`
+- **Codex:** `codex --version`
+- **Copilot:** `copilot --version`
+- **Gemini:** `gemini --version`
+
+If the LLM CLI is not installed or the command fails, use `update_llm_cli` to install it before proceeding. Do not attempt any prompt dispatch until the CLI is confirmed.
+
+## Step 1.7: Provision LLM Auth
+
+Call `provision_llm_auth`. Skip for local members - they inherit auth from the PM machine.
+
+## Step 2: Disable AI Attribution
+
+**Claude only.** Write `{"attribution":{"commit":"","pr":""}}` to `.claude/settings.json` in the member's work folder via `execute_command`. Merge if file already exists.
+
+Antigravity, Codex, Copilot, and Gemini do not support attribution config  -  skip this step for those providers.
+
+## Step 3: Detect VCS Provider
+
+Run on the member: `git remote -v`
+
+- `github.com` -> GitHub
+- `bitbucket.org` -> Bitbucket
+- `dev.azure.com` -> Azure DevOps
+
+No remotes? Ask the user for VCS provider and repo URL.
+
+## Step 4: Determine Roles
+
+Ask the user. Roles: development, code-review, testing, devops, debugging. A member can have multiple.
+
+## Step 5: Setup VCS Auth
+
+Verify auth, provision if needed. See auth-{provider}.md for provider-specific steps and required scopes per role. Skip for local members  -  they inherit the user's native git credentials.
+
+## Step 6: Check/Install Required Skills
+
+Look up the member's project + VCS + roles in skill-matrix.md. Install any missing skills.
+
+## Step 7: Add Fleet Ephemeral Files to .gitignore
+
+Run `execute_command -> echo '.fleet-task.md' >> .gitignore` on the member's work folder. These are ephemeral prompt delivery files managed by the fleet server and must never be committed to the repo.
+
+## Step 8: Update Member Status File
+
+Add to the member's status file:
+
+```
+## Member Profile
+- LLM Provider: Claude (or agy, gemini, etc.)
+- VCS: Bitbucket (kumaakh/apra-lic-mgr)
+- Roles: development, code-review
+- Auth: Bitbucket API token (verified)
+- Skills: bitbucket-devops (installed)
+```
+
+## Pre-loading credentials before dispatch
+
+If the task you are about to dispatch requires an API key, token, or password (e.g., calling an external API, pushing to a private registry, authenticating to a third-party service), store it in the credential store **before** dispatching the member.
+
+**Why:** `execute_prompt` prompts are visible in the LLM conversation. Passing raw secrets there exposes them in logs and chat history. The credential store keeps the plaintext out of the LLM entirely.
+
+**Steps:**
+1. Call `credential_store_set` with a descriptive name (e.g., `github_pat`, `npm_token`, `openai_key`)  -  Fleet opens an OOB terminal prompt for the value
+2. Pass the `sec://NAME` handle in the task prompt  -  reference by name only (e.g. `"authenticate using credential github_pat"`). The secret value is only injected server-side when `{{secure.NAME}}` appears in an `execute_command` call  -  never in AI prompt text.
+3. The member uses `{{secure.NAME}}` in `execute_command`  -  Fleet resolves the value server-side and redacts it from output before the LLM sees it
+
+**Example  -  dispatching a member that needs to push code to GitHub:**
+
+```
+# PM stores the token before dispatch
+credential_store_set  name=github_pat
+
+# PM includes in the task prompt  -  reference by name only:
+"When pushing code to GitHub, authenticate using credential github_pat."
+
+# Member uses it in a command transparently
+execute_command  command="git remote set-url origin https://token:{{secure.github_pat}}@github.com/Org/Repo.git"
+```

package/skills/fleet/permissions.md

@@ -0,0 +1,23 @@
+# Member Permissions
+
+## Before dispatching work
+
+Call `compose_permissions` with the member and role (`doer` or `reviewer` — additional roles can be added to the profiles). Optionally pass `project_folder` — the path to a folder containing a `permissions.json` ledger of previously approved permissions. The tool detects the project stack (Node.js, Python, Go, etc.) from the member's `work_folder`, selects the matching permission profile from the fleet profiles, merges any ledger grants, and delivers the right provider-native config to the member. Same call works across all agentic providers.
+
+> "Compose permissions for java-dev1 as doer, project folder ./my-project"
+
+## Permission denial during execution
+
+When `execute_prompt` output contains a permission denial, call `compose_permissions` with `grant`:
+
+> "Grant Bash(docker:*) to build-server, reason: integration tests, project folder ./my-project"
+
+The tool validates (blocks dangerous tools like sudo/env), expands co-occurrences (docker→docker-compose), delivers the updated config, and appends to the project ledger for future use.
+
+## Role switch
+
+When a member's role changes, re-run `compose_permissions` with the new role.
+
+## Never auto-granted
+
+`sudo`, `su`, `env`, `printenv`, `nc`, `nmap` — the tool rejects these. Escalate to user.

package/skills/fleet/profiles/base-dev.json

@@ -0,0 +1,18 @@
+{
+  "permissions": {
+    "allow": [
+      "Read", "Write", "Edit", "Glob", "Grep",
+      "Bash(git:*)",
+      "Bash(which:*)", "Bash(ls:*)", "Bash(cat:*)", "Bash(head:*)", "Bash(tail:*)",
+      "Bash(mkdir:*)", "Bash(cp:*)", "Bash(mv:*)", "Bash(rm:*)",
+      "Bash(find:*)", "Bash(wc:*)", "Bash(sort:*)", "Bash(diff:*)",
+      "Bash(echo:*)", "Bash(touch:*)", "Bash(chmod:*)",
+      "Bash(curl:*)", "Bash(tar:*)", "Bash(unzip:*)",
+      "Bash(grep:*)", "Bash(sed:*)", "Bash(awk:*)",
+      "Bash(tee:*)", "Bash(xargs:*)", "Bash(sleep:*)",
+      "Bash(kill:*)", "Bash(pkill:*)",
+      "Bash(bash:*)", "Bash(sh:*)",
+      "Bash(gh:*)", "Bash(jq:*)"
+    ]
+  }
+}

package/skills/fleet/profiles/base-reviewer.json

@@ -0,0 +1,14 @@
+{
+  "permissions": {
+    "allow": [
+      "Read", "Glob", "Grep",
+      "Write(docs/**)", "Write(feedback.md)", "Write(feedback-*.md)", "Write(progress.json)",
+      "Edit(docs/**)", "Edit(feedback.md)", "Edit(feedback-*.md)", "Edit(progress.json)",
+      "Bash(git:*)",
+      "Bash(which:*)", "Bash(ls:*)", "Bash(cat:*)", "Bash(head:*)", "Bash(tail:*)",
+      "Bash(find:*)", "Bash(wc:*)", "Bash(sort:*)", "Bash(diff:*)",
+      "Bash(echo:*)", "Bash(grep:*)",
+      "Bash(gh:*)", "Bash(jq:*)"
+    ]
+  }
+}

package/skills/fleet/profiles/cpp.json

@@ -0,0 +1,4 @@
+{
+  "dev": ["Bash(make:*)", "Bash(cmake:*)", "Bash(gcc:*)", "Bash(g++:*)", "Bash(clang:*)", "Bash(ninja:*)"],
+  "reviewer": ["Bash(make test:*)", "Bash(ctest:*)"]
+}

package/skills/fleet/profiles/dotnet.json

@@ -0,0 +1,4 @@
+{
+  "dev": ["Bash(dotnet:*)"],
+  "reviewer": ["Bash(dotnet test:*)"]
+}

package/skills/fleet/profiles/go.json

@@ -0,0 +1,4 @@
+{
+  "dev": ["Bash(go:*)", "Bash(gofmt:*)", "Bash(golangci-lint:*)"],
+  "reviewer": ["Bash(go test:*)", "Bash(go vet:*)", "Bash(golangci-lint:*)"]
+}

package/skills/fleet/profiles/jvm.json

@@ -0,0 +1,4 @@
+{
+  "dev": ["Bash(gradle:*)", "Bash(./gradlew:*)", "Bash(mvn:*)", "Bash(java:*)", "Bash(javac:*)"],
+  "reviewer": ["Bash(gradle test:*)", "Bash(./gradlew test:*)", "Bash(mvn test:*)"]
+}

package/skills/fleet/profiles/node.json

@@ -0,0 +1,4 @@
+{
+  "dev": ["Bash(npm:*)", "Bash(npx:*)", "Bash(node:*)", "Bash(yarn:*)", "Bash(pnpm:*)", "Bash(tsx:*)"],
+  "reviewer": ["Bash(npm test:*)", "Bash(npm run test:*)", "Bash(npm run lint:*)", "Bash(npx:*)"]
+}

package/skills/fleet/profiles/python.json

@@ -0,0 +1,4 @@
+{
+  "dev": ["Bash(python:*)", "Bash(python3:*)", "Bash(pip:*)", "Bash(pip3:*)", "Bash(pytest:*)", "Bash(uv:*)", "Bash(poetry:*)", "Bash(ruff:*)", "Bash(mypy:*)"],
+  "reviewer": ["Bash(pytest:*)", "Bash(python -m pytest:*)", "Bash(ruff:*)", "Bash(mypy:*)"]
+}

package/skills/fleet/profiles/rust.json

@@ -0,0 +1,4 @@
+{
+  "dev": ["Bash(cargo:*)", "Bash(rustc:*)", "Bash(rustup:*)"],
+  "reviewer": ["Bash(cargo test:*)", "Bash(cargo clippy:*)", "Bash(cargo check:*)"]
+}

package/skills/fleet/profiles/tpl-permissions.json

@@ -0,0 +1,5 @@
+{
+  "_example_granted_entry": { "permission": "Bash(docker:*)", "reason": "integration tests", "date": "2026-03-15" },
+  "stacks": [],
+  "granted": []
+}

package/skills/fleet/skill-matrix.md

@@ -0,0 +1,34 @@
+# Skill Matrix
+
+Maps project + role to required skills. Used during onboarding (Step 6).
+
+| Project | VCS | Role | Required Skills |
+|---------|-----|------|----------------|
+| Any | GitHub | Any | None (gh CLI sufficient) |
+| Any | Bitbucket | devops | `bitbucket-devops` |
+| Any | Bitbucket | code-review | `bitbucket-devops` |
+| Any | Bitbucket | development | None |
+| Any | Bitbucket | testing | None |
+| Any | Bitbucket | debugging | None |
+| Any | Azure DevOps | devops | `azdevops-devops` (future) |
+| Any | Azure DevOps | code-review | `azdevops-devops` (future) |
+| Any | Azure DevOps | development | None |
+| ApraPipes | Any | devops | `aprapipes-devops` |
+| StreamSurv AVMS | Any | debugging | `lvsm-log-analyzer-skill` |
+
+## Skills
+
+| Skill | Purpose |
+|-------|---------|
+| `bitbucket-devops` | Bitbucket API: create/merge PRs, manage pipelines, review code |
+| `aprapipes-devops` | ApraPipes-specific build, test, deployment |
+| `azdevops-devops` | Azure DevOps API operations (planned) |
+| `lvsm-log-analyzer-skill` | SiteManager log analysis for AVMS/BBNVR devices |
+
+## Rules
+
+1. Skills are additive — multiple roles = union of all required skills
+2. GitHub members rarely need extra skills — gh CLI covers most operations
+3. Bitbucket/Azure DevOps members need provider-specific skills for devops/code-review (LLMs lack native API knowledge without skills)
+4. Project-specific skills layer on top of VCS skills
+5. Skills are independent of the member's LLM provider — a Gemini member needs the same project skills as a Claude member. Skill selection is driven by VCS provider and project, not LLM provider.

package/skills/fleet/troubleshooting.md

@@ -0,0 +1,13 @@
+# Troubleshooting
+
+| Symptom | Action |
+|---------|--------|
+| Empty response | Check auth token expiry -> re-provision via `provision_vcs_auth` |
+| Timeout (inactivity) | `timeout_s`: fires when no stdout/stderr output arrives for N seconds (default 300s / 5 min). Applies to all members and all providers - transport-level, not provider-specific. Common cause: test runners and build tools that buffer output (npm test, vitest, cargo build) producing no output for long stretches even while active. Fix: increase `timeout_s` to 600-1200 for build/test dispatches. |
+| Timeout (total) | `max_total_s`: fires after N seconds of total elapsed time regardless of output activity. Provider-agnostic. Use for hard ceilings on long-running jobs. Set alongside `timeout_s` when you need both a silence guard and a wall-clock cap. |
+| Permission denied | Run `compose_permissions` for the member - it produces provider-native config. Claude: check `.claude/settings.local.json`. Agy: check `~/.gemini/config/hooks.json` and `mcp_config.json`. Codex: check `.codex/config.toml` approval mode. Copilot: check `.github/copilot/settings.local.json`. Gemini: check `.gemini/policies/`. |
+| Stuck after reset | Escalate model (cheap->standard->premium). Still stuck? Flag to user |
+| Auth error (401/403) | GitHub App: re-mint via `provision_vcs_auth`. Bitbucket/Azure DevOps: ask user for fresh token, provision, retry. See auth-*.md |
+| Token/password appears in command output | Use `credential_store_set` to store the secret, then reference it as `{{secure.NAME}}` in `execute_command` - Fleet redacts it to `[REDACTED:NAME]` before the LLM sees the output |
+| Need to rotate a credential without re-provisioning | Run `credential_store_delete name=<NAME>` then `credential_store_set name=<NAME>` - the new value is picked up immediately on the next `execute_command` that references `{{secure.NAME}}` |
+| Tool execution issue (unexpected behavior, missing output, silent failure) | Check `APRA_FLEET_DATA_DIR/logs/fleet-<pid>.log` for detailed execution traces. Filter by member with `jq 'select(.member_id == "<uuid>")'` or by tool with `jq 'select(.tag == "<tool>")'`. See the **Fleet Logs** section in SKILL.md for full field reference and `jq` examples. |