Surfaced during Phase A of the agent-as-decider tests. The agent did invoke
`altimate_code` for a realistic dbt question, but the spawned altimate-code
subprocess ran in `/private/tmp/altimate-hermes-integration` — a stale path
inherited from opencode's runtime cwd — not the dbt project the host
session was opened in.

All 5 tools fell back to `process.cwd()` when the caller didn't pass
`project_dir`. Plugin tools in @opencode-ai/plugin v1.17 receive a
ToolContext as the second execute() arg, whose `directory` field is the
session's project directory (per the type's own JSDoc: "Prefer this over
process.cwd() when resolving relative paths."). Switched all 5 tools to
default to `ctx.directory`, keeping the explicit `project_dir` arg as the
override.

Verified the tools still register via `opencode debug agent build`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Phases 1–6 prove tools wire up correctly. Phases A–D probe four failure
modes documented in plugin-skill-experiments/ (Issue #13 + Run 5–6) that
tool-wiring tests can't catch.

New phases (TESTING.md)

- A — agent-as-decider. Three variants (bare, softnudge, mandatory)
  ask a realistic dbt-introspection question; record whether the host
  agent picks the plugin tool or falls back to Read/Bash/grep. Same
  shape as the experiment doc's Run 5 task.
- B — in-flight dbt_packages/* edit protection. Pre-edit a model under
  dbt_packages/dbt_utils/, run altimate_dbt_build, diff. Pass = edit
  survives or build refuses with a structured error.
- C — stdin-wedge guard reality check. Temporarily flip stdio[0] from
  "ignore" to "inherit", invoke altimate_code with a trivial task; if
  it hangs the guard is necessary, if it runs cleanly the upstream bug
  is fixed.
- D — cross-warehouse smoke. Delegate a comparison across two configured
  dbt profiles (eastman_source_mssql + eastman_migration); capture
  altimate-code's internal tool calls + the warehouse_test outcomes.

TESTING.md also documents:
- Run-artifact discipline: per-phase per-timestamp dir under
  `.scratch/runs/`, full bytes, never overwritten. Aborted runs are
  renamed `__ABORTED_<reason>` rather than deleted.
- Where to fix things: plugin-side problem → patch directly + WORKLOG
  entry; upstream problem → stop and report.

Results (TESTING_RESULTS.md + WORKLOG.md)

- A — ⚠️ soft. 3/3 variants picked a plugin tool (`altimate_dbt_columns`),
  none touched Read/Bash/grep. The strict pass criterion ("agent calls
  `altimate_code`") was not met in any variant. Whether the agent ever
  picks `altimate_code` is therefore unanswered by this round.
- B — ❌ FAIL. Reproduced upstream Issue #13 verbatim: sha_before ==
  sha_after_build with a successful exit code. The edit was clobbered
  silently. Reported as an upstream finding against
  `altimate-dbt-integration/src/dbtIntegrationAdapter.ts:390-408`. No
  plugin-side mitigation possible.
- C — ✅ pass. The wedge does not reproduce with stdin: "inherit" in
  altimate-code 0.8.3. Kept the guard as belt-and-suspenders; refreshed
  the comment in `plugins/altimate-code/index.ts:175-179` with the
  re-validation date and version.
- D — ⚠️ inconclusive on the strict criterion. Plugin shim drove
  altimate-code's `warehouse_test` against both warehouses; Snowflake
  connected, MSSQL connector failed (env gap consistent with Issue #4 +
  #7 — pre-baked dbt-sqlserver/FreeTDS/ODBC not present). Plugin layer
  worked; the actual comparison only ran against Snowflake.

The verdict language at the top of TESTING_RESULTS.md is tightened:
"all phases pass" now means *wiring works AND the agent reliably selects
the plugin tool when prompted realistically* — not just *the tools register
and run when forced*.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Pre-flight cleanup before flipping the repo to public visibility.

- `README.md`: replace the `git clone + cat >> opencode.json` workflow
  with the canonical `opencode plugin github:owner/repo --global`
  command, which writes the entry into the singular `plugin` array
  automatically. Adds a note documenting opencode's `plugin` /
  `skills.paths` schema keys vs the wrong `plugins` / `skills: [...]`
  ones earlier drafts used. The old snippet was broken — the wrong
  key was silently ignored by opencode and the plugin never loaded.
- `TESTING.md`: drop the absolute `/Users/haider/Documents/…` path to
  the experiments deliverable. Replaced with a relative reference to
  "our `plugin-skill-experiments/` deliverable series".
- `TESTING_RESULTS.md` + `WORKLOG.md`: drop the
  `/private/tmp/altimate-hermes-integration` reference from the CWD
  bug post-mortem — it was debug context, not load-bearing for a
  public reader.
- `WORKLOG.md`: brings forward the "AI-7072 plugin-side mitigation:
  considered, rejected" entry that was sitting unpushed on the
  `fix/AI-7072-dbt-packages-clobber-warning` branch. Documents the
  reasoning so the next session doesn't reflexively re-introduce a
  partial mitigation for an upstream-fixable bug.

Codex was unavailable at commit time (OpenRouter saturation across
gpt-5.4-mini / sonnet-4.6 / haiku-4.5 routes — "high demand" errors
on every attempt). Self-reviewed in lieu; codex can re-review against
the pushed state when the route is back.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

OCR review of the pre-public-flip bundle flagged that the
`process.cwd()` → `ctx.directory` fix from b6fc209 left a residual
silent-failure path: if a session has no `ctx.directory` populated
AND the caller doesn't pass `project_dir`, the subprocess would
either receive the literal string "undefined" as its `--dir` (in
`altimate_code`) or silently inherit opencode's runtime cwd (in the
4 `altimate_dbt_*` tools — same shape as the original AI-7072 / Phase A
regression we already fixed once).

Changes:
- Extract `resolveCwd(project_dir, ctxDirectory)` and `noCwdError(label)`
  helpers (`string | undefined` for both inputs to honestly model
  runtime nullability per a follow-up OCR comment).
- Wire the guard into all 5 tool execute() paths so a missing cwd
  produces a structured `ERROR: No working directory available for
  <tool>: pass project_dir, or open the opencode session from a
  project directory so ctx.directory is populated.` rather than a
  silent wrong-dir subprocess.
- Add missing `.describe()` on `altimateDbtBuild` `project_dir` arg
  (was the only one of the 4 dbt tools without it after b6fc209).

Verified all 5 tools still register via `opencode debug agent build`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

End-to-end test of the README's `opencode plugin github:owner/repo`
path against opencode 1.17 exposed two gaps that blocked the
standard install:

1. **Package shape rejected by the plugin loader.** opencode 1.17's
   plugin resolver checks for one of `exports["./server"]`,
   `exports["./tui"]`, top-level `main`, or `oc-themes`. Our package
   only declared `exports["."]`, so the install bailed with
   `No plugin targets found … does not expose plugin entrypoints in
   package.json`. Added `exports["./server"]` alongside the existing
   `exports["."]` to satisfy the loader without breaking other
   resolvers (bun add / npm install already worked via the bare
   exports map).

2. **Skills didn't auto-register.** `opencode plugin install` wires
   up the tool surface but doesn't touch `skills.paths`, so the 11
   bundled SKILL.md files under `skills/*` were invisible until the
   user hand-edited their global `opencode.jsonc`. Added a `config`
   hook on the Plugin that derives this module's location via
   `fileURLToPath(import.meta.url)` and merges the 11 absolute skill
   directory paths into `cfg.skills.paths` at plugin load.
   Idempotent (de-dup via Set), wrapped in try/catch so a missing
   subtree degrades to tools-only rather than failing plugin load.
   Type alias `CfgWithSkills` extracted per OCR review.

Verified end-to-end against `opencode plugin file:<repo> --global`
from a wiped `~/.config/opencode`: 5/5 tools registered, 11/11
skills loaded, no false-positives.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>