docs(planning): D18 + Phase 1.4 re-scope (skip Cloud Sandbox) + RUNBOOKS API setup

Phase 1.4 kickoff. The plan-row originally read "Provision Splunk Cloud
Sandbox or paid trial for API-based dynamic checks" — that was
over-scoped. The AppInspect HTTP API (`appinspect.splunk.com/v1/app/validate`)
authenticates with splunk.com Developer credentials (D15), not a
Cloud-tenant credential. The Cloud Sandbox is only needed if Phase 1.6
dynamic checks surface issues requiring hands-on Cloud-tenant runtime
probing — a separate concern from the AppInspect API itself.

Endpoint probe this turn confirmed `appinspect.splunk.com/v1/info`
returns `{"api_version": "v1", "appinspect_version": "4.2.0"}` —
exact match for the pin in `.github/workflows/appinspect.yml`
(Phase 1.2 / commit `0c826e8`). So Phase 1.6 dynamic findings will
not carry ruleset-drift artifacts vs the Phase 1.3 local baseline.

Three changes in this commit:

1. `docs/PUBLIC_RELEASE_PLAN.md` §1 Decisions: new D18 capturing the
   re-scope, alternatives considered (Cloud Sandbox / paid trial), and
   reversal cost (low — can provision Sandbox at any later phase).
   The D18 cell shape matches the §1 header's 3 columns (D17 has a
   pre-existing 4-cell anomaly that pre-dates this commit; leaving
   it for a future doc-polish sweep rather than reshaping the whole
   table mid-Phase-1).

2. `docs/PUBLIC_RELEASE_PLAN.md` Phase 1.4 row: re-scoped + marked
   ⚠️ PARTIAL with a flip-to-✅ criterion explicitly tied to the
   user running `gh secret set SPLUNK_DEV_USERNAME` and
   `gh secret set SPLUNK_DEV_PASSWORD`, then `gh secret list`
   confirming both are present. Header status line updated to
   reflect Phase 1.4 ⚠️ PARTIAL + next step.

3. `docs/RUNBOOKS.md`: new "AppInspect API — Credential Setup"
   section (after the existing Tag Signing section). Covers
   prerequisites, the anonymous endpoint probe verifying network
   reachability + version alignment, the two `gh secret set`
   commands, secret-naming convention (`SPLUNK_DEV_*` namespace
   intentional — covers both AppInspect API + future Splunkbase
   publishing API, both use the same credential), rotation
   procedure, and scope re-statement (Sandbox provisioning
   explicitly out-of-scope per D18).

Phase 1.5 (next) will wire `splunk/appinspect-api-action` against
those two secrets in a new workflow. End-to-end auth validation is
deferred to that first workflow run — the action handles the
splunk.com JWT exchange internally, so a separate hand-run round-trip
from the local shell adds no information beyond what the workflow's
first run will surface.

Doc-drift hook passes on all 29 docs.

Author: RelativisticJet

docs/PUBLIC_RELEASE_PLAN.md

@@ -2,8 +2,8 @@
 
 > Plan owner: Oleh (@RelativisticJet)
 > Created: 2026-05-13
-> Status: **Phase 0 — Foundation cleanup COMPLETE for all 15 rows.** Phase 1 in progress — **1.1, 1.2, 1.3 closed 2026-05-17** (Splunk Dev account + dev license + AppInspect CI workflow + first AppInspect CLI baseline with full per-finding triage). Next: 1.4 (Splunk Cloud Sandbox / paid trial provisioning).
-> Updated: 2026-05-17 (Phase 1.2 + 1.3 landed: `.github/workflows/appinspect.yml` enforcing 0-blocker gate on both `splunk-platform-standalone` and `cloud` profiles, `docs/APPINSPECT_FINDINGS.md` baseline + warning triage. Fresh run reproduced + fixed an `app.manifest:2.0.0` ↔ `app.conf:1.0.0-rc1` drift left over from Phase 0.8; `docs/RELEASE_CHECKLIST.md` §3.5 pre-flight extended with a 5th check so the gap can't recur silently)
+> Status: **Phase 0 — Foundation cleanup COMPLETE for all 15 rows.** Phase 1 in progress — **1.1, 1.2, 1.3 closed 2026-05-17**; **1.4 ⚠️ PARTIAL** (re-scoped per D18 — skip Cloud Sandbox, use existing splunk.com Dev creds with the AppInspect HTTP API; setup procedure landed in RUNBOOKS.md, awaiting user `gh secret set`). Next: complete 1.4 secrets step → Phase 1.5 (`appinspect-api-action` workflow wiring).
+> Updated: 2026-05-17 (Phase 1.4 re-scoped: D18 added to §1 locking the decision; `docs/RUNBOOKS.md` gained "AppInspect API — Credential Setup" section documenting the `gh secret set` workflow. Phase 1.2 + 1.3 landed earlier this date: `.github/workflows/appinspect.yml` enforcing 0-blocker gate on both `splunk-platform-standalone` and `cloud` profiles + `docs/APPINSPECT_FINDINGS.md` baseline + warning triage; fresh AppInspect run reproduced + fixed an `app.manifest:2.0.0` ↔ `app.conf:1.0.0-rc1` drift; `docs/RELEASE_CHECKLIST.md` §3.5 pre-flight extended)
 
 This document is the canonical plan for taking `wl_manager` from
 private-internal to public open-source on GitHub, then to a listed
@@ -42,6 +42,7 @@ explicit user re-decision.
 | D15 | **Splunk Developer / Splunkbase publisher name: "Oleh Bezsonov"** (real name, not `@RelativisticJet` handle). Account email: `communicate.oleh@gmail.com`. Created at dev.splunk.com 2026-05-13. | Unifies identity with D5 LICENSE copyright. Real name is publicly visible on every Splunkbase listing under this account — trade-off accepted. Avoids future legal-entity transfer friction that a handle-as-brand might create. Matches convention of established Splunkbase community apps (e.g., TrackMe V1 published as "Guilhem Marchand"). Reversible by emailing Splunk Developer Support if an LLC is ever formed. |
 | D16 | **Docs hosting URL: GitHub Pages default (`https://relativisticjet.github.io/wl_manager/`), no custom domain for v1.0.0 GA.** Decided 2026-05-17 during pre-Phase-1 §5a sweep. | Pre-public there are no readers; a custom `.dev` domain costs $15-30/yr ongoing for a vanity URL that nobody is asking for yet. URL portability isn't a concern — both the GitHub handle (`@RelativisticJet`, owned) and the repo name (`wl_manager`) are stable. Brand identity comes from the project name in headings/badges, not the URL bar. Revisit if/when traction warrants a vanity URL or the handle ever changes. Reversal cost: low — buy domain, point a CNAME at `relativisticjet.github.io`, set the domain in GitHub Pages settings + the `site_url` field in `mkdocs.yml`. ~1 hour after domain purchase. |
 | D17 | **Tag-signing path: SSH (key reused for auth + signing) under RelativisticJet identity.** ed25519 key `SHA256:QIzLvkfiF/tdy2M9m5HDEC3wJstge+NWBiGeEJ5KuNo` uploaded to the RelativisticJet GitHub account as both Authentication and Signing key. Per-repo git committer set to `Oleh Bezsonov <20013626+RelativisticJet@users.noreply.github.com>` so signature verification ties to the account owning the signing key. End-to-end verified 2026-05-17 via throwaway test tag (GitHub returned `verified=true, reason=valid`). | Alternatives considered: (a) GPG-key signing via Gpg4win — more setup, broader downstream tool support, but the Git-bundled GPG 2.4.9 is keyboxd-broken on Windows so it requires installing a full Windows GPG distribution; (b) keep `wildleo91` git identity and upload the same signing key to the `wildleo91` GitHub account too — lowest friction but leaves the repo-owner-vs-commit-author mismatch in the public eye. SSH won because: simpler setup, no extra software install on Windows, Git ≥ 2.34 supports it natively (norm since late 2021, well before any plausible production-Splunk install date). The identity switch to RelativisticJet was orthogonal but landed in the same change because tag verification requires the tagger email to map to the account that owns the signing key — this unifies the public face of the repo: commit author + repo owner + Splunk publisher (D15) + LICENSE copyright (D5) all read "Oleh Bezsonov" / RelativisticJet going forward. Historical commits remain attributed to `wildleo91` — no history rewrite, since rewriting would invalidate any existing forks and the prior attribution is internally consistent. | Low — to switch to GPG: install Gpg4win, generate key, upload to GitHub, change `git config gpg.format=openpgp` and `user.signingkey=<gpg-keyid>`. To revert to wildleo91 identity for this repo: `git config --local --unset user.email && git config --local --unset user.name` (falls back to the global config). The signing key itself doesn't change in either reversal — it's the orchestration around it. |
+| D18 | **Phase 1.4 re-scope: skip Splunk Cloud Sandbox provisioning; use the existing splunk.com Developer credentials (D15) directly with the AppInspect HTTP API.** Decided 2026-05-17 during Phase 1.4 kickoff. | The AppInspect HTTP API at `appinspect.splunk.com/v1/app/validate` authenticates with splunk.com Developer credentials, not a Cloud-tenant credential. Endpoint probe this turn confirmed `appinspect.splunk.com/v1/info` returns `{"api_version": "v1", "appinspect_version": "4.2.0"}` — exact match for the version pinned in `.github/workflows/appinspect.yml` (Phase 1.2 / commit `0c826e8`), so Phase 1.6 dynamic findings will not carry ruleset-drift artifacts vs the Phase 1.3 local baseline. **Alternatives**: (a) provision Splunk Cloud Sandbox (free, may need approval per plan risk R1.2, ~1-2 hr + possible wait); (b) paid Splunk Cloud Platform trial (~1 hr, $$). Both are necessary ONLY for actual Cloud-runtime install testing — a separate concern from the AppInspect API itself. Splunkbase Cloud Vetting gates on AppInspect API pass + manual review, not on customer-side Cloud installs. Path (c, chosen) defers Sandbox provisioning to AFTER Phase 1.6 if dynamic checks surface specific Cloud-runtime issues that need hands-on triage. **Reversal cost**: low — provisioning a Cloud Sandbox at any later phase remains an option; the D15 splunk.com Developer account is already eligible to apply. The repo-side artifact (`docs/RUNBOOKS.md` "AppInspect API — Credential Setup" section) stays useful regardless of whether a Sandbox is ever provisioned. To reverse: apply for a Sandbox at dev.splunk.com and add a new Phase 1.4b row to this plan covering the actual Cloud-install runtime testing scope. |
 
 ---
 
@@ -140,7 +141,7 @@ timeline slips, scope does not.
 | 1.1 ✅ 2026-05-16 (per Decision D15 in §1; marked retroactively during 2026-05-15 gap review as G3; demoted to ⚠️ PARTIAL on 2026-05-16 per QA-C5 finding; re-promoted to ✅ same-day after Phase 1.1.1 closure landed in `docs/DECISION_LOG.md` "Followups & acknowledgements" section) | Sign up for Splunk Developer account at dev.splunk.com. Account `Oleh Bezsonov` / `communicate.oleh@gmail.com` is active per D15. **Phase 1.1.1 closed 2026-05-16**: credentials stored in maintainer's personal password manager; TOTP 2FA enabled on the account; recovery codes stored separately from the password; linked Gmail has its own 2FA + recovery — see the 2026-05-16 row in `docs/DECISION_LOG.md` followups subsection. Storage method intentionally not documented further in the public log (the ack is the proof; the credential location stays out-of-repo). Reversibility note per D15: account transferable by emailing Splunk Developer Support if an LLC is ever formed. | Account active, credentials stored securely (method documented OUT-OF-REPO; ack lives in DECISION_LOG.md followups subsection) | 15 min |
 | 1.2 ✅ 2026-05-17 | Wire `splunk/appinspect-cli-action` in new `.github/workflows/appinspect.yml` | Workflow runs against built .spl with `splunk-platform-standalone` profile. **Landed**: `.github/workflows/appinspect.yml` runs both `splunk-platform-standalone` AND `cloud` profiles on push/PR/manual; pins Python 3.11 (per Phase 0.0 wheel-availability finding); enforces a hard gate (0 errors / 0 failures / 0 future_failures) via inline Python summary parse; uploads JSON reports as 30-day artifacts; concurrency-coalesces in-flight runs on the same ref. Uses `pip install splunk-appinspect` directly rather than the `splunk/appinspect-cli-action` wrapper to stay byte-for-byte aligned with the local re-run command at `docs/APPINSPECT_FINDINGS.md` §6 and to avoid a third-party-action version pin; swap is trivial if ever preferred. | 30 min |
 | 1.3 ✅ 2026-05-17 | First AppInspect CLI run + triage findings → `docs/APPINSPECT_FINDINGS.md` | All findings logged by severity (error / warning / manual_check); each has a fix-or-defer decision. **Landed**: `docs/APPINSPECT_FINDINGS.md` written. Standalone 160 success / 0 failure / 0 future_failure / 6 warning; Cloud 157 / 0 / 0 / 5. Zero delta vs Phase 0.0 build-660 baseline. The fresh run surfaced an `app.manifest` version drift (Phase 0.8 demoted `app.conf` to `1.0.0-rc1` but missed `app.manifest`, still at `2.0.0`); fixed in same commit + Phase 0.11b §3.5 pre-flight extended with a 5th check (`info.id.version` in `app.manifest`) so the gap can't recur silently. All 6/5 warnings re-triaged in the doc with per-finding justification (4 high-frequency cron searches accepted as security-critical detection latency, not cosmetic). | 2-4 hr |
-| 1.4 | Provision Splunk Cloud Sandbox or paid trial for API-based dynamic checks | Trial active; credentials in GitHub Actions secrets | 1-2 hr |
+| 1.4 ⚠️ PARTIAL 2026-05-17 (re-scoped per D18; setup procedure landed; awaiting user `gh secret set`) | Per D18, use existing splunk.com Developer credentials (D15) with the AppInspect HTTP API; defer Cloud Sandbox unless Phase 1.6 surfaces hands-on triage need. **Landed this turn**: D18 in §1, this row's re-scope, and `docs/RUNBOOKS.md` "AppInspect API — Credential Setup" section documenting (a) anonymous endpoint probe (`appinspect.splunk.com/v1/info` → AppInspect 4.2.0, matches our local pin) and (b) the `gh secret set SPLUNK_DEV_USERNAME` + `SPLUNK_DEV_PASSWORD` commands the user runs against `RelativisticJet/wl_manager`. **Flip to ✅ when**: user has run both `gh secret set` commands and confirmed via `gh secret list --repo RelativisticJet/wl_manager` (both secrets present); first Phase 1.5 workflow run will be the end-to-end auth validation. | API access confirmed via endpoint probe (AppInspect 4.2.0 matches local pin); credentials stored in GitHub Actions secrets (`SPLUNK_DEV_USERNAME`, `SPLUNK_DEV_PASSWORD`) | 30 min |
 | 1.5 | Wire `splunk/appinspect-api-action` workflow with `cloud` + `self-service` tags | API workflow fires, dynamic checks complete | 30 min |
 | 1.6 | First AppInspect API run — **surface Cloud-cert blockers** | Findings appended to APPINSPECT_FINDINGS.md. **Critical**: assess `wl_fim.py` / `wl_fim_watch.py` / `wl_expiration_cleanup.py` viability for Cloud profile. **If estimated refactor >2 weeks, escalate per D7 before continuing** | 1 day investigation |
 | 1.7 | Fix all AppInspect "error"-severity findings | Each as atomic commit. AppInspect re-runs green | 1 day – several weeks (per 1.6 outcome) |

docs/RUNBOOKS.md

@@ -508,3 +508,80 @@ For wl_manager specifically (downstream is Splunk Enterprise admins running `git
 
 **When the first signed tag fails verification**: most likely causes are (a) the public key wasn't uploaded to GitHub yet, (b) the email on the GitHub key doesn't match the git committer email, or (c) on Windows, `gpg.program` points at the broken Git-bundled gpg.exe instead of the Gpg4win install. `git verify-tag --verbose v1.0.0-rc1` shows the specific failure mode.
 
+### AppInspect API — Credential Setup
+
+Phase 1.4 setup procedure (see `docs/PUBLIC_RELEASE_PLAN.md` §1 D18 for the
+re-scope decision). Phase 1.5 will wire `splunk/appinspect-api-action` in a
+new workflow that reads two GitHub Actions secrets to authenticate against
+the hosted AppInspect HTTP API (`appinspect.splunk.com/v1/app/validate`).
+
+**Prerequisites:**
+
+- A splunk.com Developer account (Phase 1.1 / D15; account `Oleh Bezsonov` /
+  `communicate.oleh@gmail.com`, created 2026-05-13)
+- Credentials accessible (Phase 1.1.1 / DECISION_LOG.md followups —
+  password manager + TOTP recovery codes)
+- `gh` CLI authenticated against the `RelativisticJet` GitHub account
+  (`gh auth status` should show that account)
+
+**Step 1 — Confirm API endpoint is reachable.** This is anonymous and
+requires no credentials; it verifies the network path:
+
+```bash
+curl -s https://appinspect.splunk.com/v1/info
+# expected: {"api_version": "v1", "appinspect_version": "4.2.0"}
+```
+
+The `appinspect_version` returned MUST match the pin in
+`.github/workflows/appinspect.yml` (Phase 1.2). If Splunk has bumped
+the hosted version, see the bump procedure inside the workflow's
+"Install splunk-appinspect" step comment — same version on both sides
+keeps Phase 1.6 dynamic findings comparable to Phase 1.3 local
+findings.
+
+**Step 2 — Store the splunk.com Developer credentials as GitHub
+Actions secrets.** Run these against the upstream repo; `gh secret set`
+prompts for the value interactively (does NOT take it as a CLI arg —
+that would put the password in shell history):
+
+```bash
+gh secret set SPLUNK_DEV_USERNAME --repo RelativisticJet/wl_manager
+#   <paste the Developer-account username when prompted>
+
+gh secret set SPLUNK_DEV_PASSWORD --repo RelativisticJet/wl_manager
+#   <paste the password when prompted>
+```
+
+**Step 3 — Verify both secrets are registered.** Names + last-updated
+timestamps only; values are not retrievable after creation:
+
+```bash
+gh secret list --repo RelativisticJet/wl_manager
+# expect to see both SPLUNK_DEV_USERNAME and SPLUNK_DEV_PASSWORD listed
+```
+
+**Step 4 — End-to-end auth validation.** Deferred to Phase 1.5's first
+workflow run. `splunk/appinspect-api-action` does the splunk.com JWT
+exchange internally; if either secret is wrong, that workflow fails
+with a clear 401 on the login call. There is no benefit to a separate
+hand-run round-trip from the local shell — the action's auth flow is
+the canonical path.
+
+**Secret naming convention:** `SPLUNK_DEV_*` covers both the AppInspect
+API (Phase 1.5/1.6) and any future Splunkbase publishing API call
+(Phase 3) — both use the same splunk.com Developer credential. Do NOT
+introduce a separate `APPINSPECT_*` or `SPLUNKBASE_*` namespace.
+
+**Rotation:** if the password is rotated upstream (suspected exposure
+or scheduled refresh), re-run Step 2 with the new value. GitHub
+Actions secret-set is overwrite-safe; the previous value is replaced
+atomically and downstream workflows pick up the new value on their
+next run with no further action.
+
+**Scope (re-scope per D18):** this section does NOT cover provisioning
+a Splunk Cloud Sandbox or paid Splunk Cloud Platform trial. Those are
+separate artifacts needed only if Phase 1.6 dynamic checks surface
+issues that require hands-on Cloud-tenant runtime probing. If that
+need arises, a follow-up Phase 1.4b row will be added to the plan
+documenting the Sandbox provisioning steps.
+