release(v1.0.1): remove check_for_updates=false (Splunkbase rejection)

Packaging patch for v1.0.0. Uploading wl_manager-1.0.0.spl to
Splunkbase was rejected at the package-validation gate with:

  "The check_for_updates field found in app.conf must not be disabled."

Root cause: [package].check_for_updates = false in default/app.conf
was inherited boilerplate, kept during Phase 1.6 because AppInspect
4.2.0's check_for_updates_disabled rule fires only as a warning, which
we triaged as acceptable (see docs/APPINSPECT_FINDINGS.md F12).
Splunkbase enforces the same condition as a HARD rejection at upload
time -- a different gate from the AppInspect API workflow we shipped
in CI. The Phase 1.6 triage assumed the two pipelines were equivalent;
they aren't. Lesson recorded in docs/DECISION_LOG.md row 2026-06-01.

Fix: remove the check_for_updates = false line entirely. Splunk's
default is true, which is what Splunkbase requires. The setting is
not load-bearing for any feature of this app -- it controls whether
Splunk's launcher polls Splunkbase for new versions of the app, which
is the standard customer-facing capability we have no reason to
disable.

Files in this commit:
- default/app.conf: drop check_for_updates line; build 670 -> 671;
  [launcher].version + [id].version 1.0.0 -> 1.0.1; expanded the
  in-file comment to document why the value is omitted.
- app.manifest: info.id.version 1.0.0 -> 1.0.1; releaseDate updated.
- appserver/static/whitelist_manager.js: urlArgs _b=670 -> _b=671
  (Splunk's 1-year static-asset cache otherwise serves stale JS).
- CHANGELOG.md: new v1.0.1 entry with full why-and-what record.
- docs/DECISION_LOG.md: new 2026-06-01 row with the
  AppInspect-vs-Splunkbase gate divergence + the maintenance rule
  that prevents re-introduction.
- docs/APPINSPECT_FINDINGS.md: F12 post-mortem appended -- the
  Phase 1.6 triage of "value is fine, only stanza placement matters"
  was wrong; Splunkbase blocks at upload regardless of AppInspect's
  verdict.

Pre-flight passing on this commit:
- §3.5 4-source version pre-flight: app.conf [launcher].version =
  app.conf [id].version = app.manifest info.id.version = 1.0.1;
  [package].id = [id].name = wl_manager.
- Build/urlArgs alignment: build 671 = whitelist_manager.js _b=671.
- doc-drift hook: OK (37 docs / build 671).
- check_for_updates regression check: confirmed not present in
  default/app.conf at value `false`.

No app-code or behavior changes. The shipped .spl differs from
wl_manager-1.0.0.spl only in default/app.conf (one line removed,
build/version bumped) and the version-pinned files listed above.
Migration: install wl_manager-1.0.1.spl over the existing app.

Author: RelativisticJet

CHANGELOG.md

@@ -4,6 +4,72 @@ All notable changes to this project will be documented in this file.
 
 ---
 
+## [1.0.1] - 2026-06-01
+
+**Splunkbase upload patch.** Bumps `default/app.conf [launcher].version`
+and `app.manifest:info.id.version` to `1.0.1`, build `671`. No app-code
+or feature changes — a single packaging fix so v1.0.0's content can
+clear the Splunkbase upload gate.
+
+### Why this exists
+
+Uploading `wl_manager-1.0.0.spl` to Splunkbase was rejected at the
+package-validation step with:
+
+> The `check_for_updates` field found in `app.conf` must not be disabled.
+
+The setting `[package].check_for_updates = false` in
+`default/app.conf` (present since long before public release, value
+inherited from boilerplate, not from a recorded product decision) is
+treated by AppInspect 4.2.0's `check_for_updates_disabled` rule as a
+**warning** — which we triaged as acceptable during Phase 1.6 (see
+`docs/APPINSPECT_FINDINGS.md` F12). But Splunkbase's package-validation
+step (a different gate, run at upload time, not equivalent to the
+AppInspect API workflow we shipped in CI) enforces "must not be
+disabled" as a **hard rejection**. The two pipelines disagreed; the
+Phase 1.6 triage assumed they were equivalent; they aren't.
+
+### What changed
+
+- **`default/app.conf` `[package]`.** Removed the
+  `check_for_updates = false` line. Splunk's default is `true`, which
+  is what Splunkbase requires. The setting is not load-bearing for any
+  feature of the app — checking for updates is an end-user-facing
+  capability that customers should be allowed to use.
+- **Build/version bumps.** `[install].build` 670 → 671;
+  `[launcher].version` + `[id].version` 1.0.0 → 1.0.1; `app.manifest`
+  `info.id.version` matched. `appserver/static/whitelist_manager.js`
+  `urlArgs: "_b=671"` keeps the AMD cache-bust in sync with the build
+  number (Splunk's 1-year static-asset cache otherwise serves stale
+  JS — see `docs/SPLUNK_QUIRKS.md`).
+- **`docs/DECISION_LOG.md`.** Added a new row recording the
+  AppInspect-vs-Splunkbase gate divergence so future contributors
+  don't re-introduce `check_for_updates = false`.
+- **`docs/APPINSPECT_FINDINGS.md`.** F12 post-mortem note: the
+  Phase 1.6 triage of "false value is acceptable, only the placement
+  matters" was wrong. Splunkbase blocks at upload regardless of
+  AppInspect's verdict.
+
+### What did not change
+
+No code paths in `bin/`, no behavior visible to analysts/admins, no
+audit-trail schema, no REST API contract. The shipped `.spl` differs
+from `wl_manager-1.0.0.spl` only in `default/app.conf` (one line
+removed, build/version bumped) and the version-pinned files listed
+above.
+
+### Migration notes for existing v1.0.0 installs
+
+None. v1.0.0 installs that were deployed manually (outside Splunkbase)
+continue to work — `[package].check_for_updates` did not affect any
+runtime behavior of this app. The only effect of removing it is that
+Splunk's built-in "check for app updates" UI will now query Splunkbase
+for newer versions (which is the standard Splunk behavior all
+production apps allow). To upgrade in place, install
+`wl_manager-1.0.1.spl` over the existing app.
+
+---
+
 ## [1.0.0] - 2026-05-24
 
 **General Availability release.** Bumps `default/app.conf [launcher].version`
@@ -55,7 +121,7 @@ changes affecting customer behavior.
 - §3.5 version-tag consistency pre-flight: passes (`app.conf
   [launcher].version` = `app.conf [id].version` = `app.manifest
   info.id.version` = `1.0.0`; `[package].id` = `[id].name` = `wl_manager`).
-- Doc-drift hook: PASS (37 docs / build 670).
+- Doc-drift hook: PASS (37 docs / build 670 (historical, v1.0.0 GA cut)).
 - QA Second-pass review: PASS, zero gaps.
 - `.github/workflows/release.yml` Sigstore keyless signing dry-run
   verified 2026-05-13 — the v1.0.0 tag push will trigger production

app.manifest

@@ -5,7 +5,7 @@
     "id": {
       "group": null,
       "name": "wl_manager",
-      "version": "1.0.0"
+      "version": "1.0.1"
     },
     "author": [
       {
@@ -14,7 +14,7 @@
         "company": null
       }
     ],
-    "releaseDate": "2026-05-24",
+    "releaseDate": "2026-06-01",
     "description": "Manage detection-rule CSV whitelists with diff-based audit trail. Provides a web-based interface for viewing, editing, adding, and removing whitelist entries with full change tracking, expiration management, and role-based access control.",
     "classification": {
       "intendedAudience": "Security Operations",

appserver/static/whitelist_manager.js

@@ -11,7 +11,7 @@
 // disk cache. Splunk serves /static/@<server-hash>/... with Cache-Control:
 // public, max-age=31536000; without urlArgs, bumped build numbers don't force
 // a re-fetch and clients run stale JS until they hard-refresh.
-require.config({ urlArgs: "_b=670" });
+require.config({ urlArgs: "_b=671" });
 require([
     "jquery",
     "underscore",

default/app.conf

@@ -5,32 +5,34 @@
 
 [install]
 is_configured = false
-build = 670
+build = 671
 
 [launcher]
 author       = Oleh Bezsonov
 description  = Manage detection-rule CSV whitelists with inline editing, approval workflows, version control, and diff-based audit trail
-version      = 1.0.0
+version      = 1.0.1
 
 [ui]
 is_visible = true
 label      = Whitelist Manager
 
 [id]
 name              = wl_manager
-version           = 1.0.0
+version           = 1.0.1
 
 # AppInspect 4.2.0 has both `check_for_valid_package_id` (looks at the
 # new [id] stanza) and `check_for_updates_disabled` (looks at the
 # legacy [package] stanza). It also enforces that the [package] id
 # matches the [id] name — so `[package].id` and `[id].name` must
 # coexist with matching values, and they do.
 #
-# `check_for_updates` lives ONLY in [package] (SLIM rejects it in [id]
-# as an unknown setting in that stanza; Phase 1.6 hosted-API run
-# 26000914082 surfaced this as the F12 finding — see
-# docs/APPINSPECT_FINDINGS.md §5.2). The legacy stanza is the canonical
-# home for the setting; defensive duplication in [id] was over-cautious.
+# `check_for_updates` is intentionally OMITTED (default is `true`).
+# Splunkbase package validation REJECTS the upload at the gate if it
+# is set to `false`, with error: "The check_for_updates field found
+# in app.conf must not be disabled." AppInspect 4.2.0's
+# `check_for_updates_disabled` rule only warns; Splunkbase enforces
+# it as a hard gate. The two pipelines disagree — Splunkbase wins,
+# because that is the upload destination. See v1.0.1 CHANGELOG +
+# DECISION_LOG.md row 2026-06-01 for the full divergence record.
 [package]
 id                = wl_manager
-check_for_updates = false

docs/APPINSPECT_FINDINGS.md

@@ -389,6 +389,7 @@ run `26002056326` passing both profiles green. Outcome per F-finding:
 | F1 | manifest `Enterprise` version requirement | partial — manifest now `"9.3"` (operationally honest; only Splunk-supported version as of 2026-05-17), but SLIM still rejects it. Suppressed via expect.yaml. | `5757ade` + `628a2b3` |
 | F2–F11 | SLIM spec drift on `python.version` / `python.required` | unchanged in source (still required by static AppInspect); suppressed at the dynamic-API layer via expect.yaml. | `628a2b3` |
 | F12 | redundant `[id].check_for_updates` | **fixed in source** by removing the redundant line; `[package]` is now the sole home. | `d40e1b9` |
+| F12 post-mortem (2026-06-01) | `[package].check_for_updates = false` itself | **value also removed in v1.0.1** — Splunkbase upload-time package validation rejected `wl_manager-1.0.0.spl` with "The check_for_updates field found in app.conf must not be disabled." AppInspect's `check_for_updates_disabled` only warns; Splunkbase enforces it as a hard gate. The Phase 1.6 triage (which kept the value at `false`) was wrong: it focused only on the F12 stanza-placement question, not the value choice. v1.0.1 removes the `check_for_updates` line entirely so Splunk's default (`true`) applies. See `docs/DECISION_LOG.md` 2026-06-01 row for the full divergence record + the maintenance rule that prevents re-introduction. | `<v1.0.1 release commit>` |
 
 Three CI iterations confirmed SLIM rejects every Enterprise version
 format we can produce without Splunk-private documentation: