Production-ready setup: document, skill, and validate profile

Summary

Document what a production-ready SPA environment must set, teach agents/humans to apply it, and verify it in code. Today README says SPA may be used for production; examples, schema, and spa validate still assume lab defaults (RF/SF 2, trial licenses, open lab SGs, default-ish passwords). spa-create-config already has an intent of config-test | app-lab | production-like but that is checklist prose, not a gate.

This is not full capacity planning or a PS substitute (rf-sf-sizing.md). It is a must-settings profile: if you claim production (or spa validate in that mode), these knobs must be present and lab-unsafe defaults must fail.

Document

• User-guide chapter (issue #61 can index it): production vs lab; must / should / out of scope.
• Feature catalog (#53): a profile.production (or similar) that lists required keys, when_not_to_use for lab-only topologies (S1), and pointers to TLS, secrets, licenses.
• Skill: extend spa-create-config (or a small dedicated skill) so agents load the same list and do not invent production from C1-lab examples. AGENTS.md: never call a lab example “production” unless the profile passes.

Pickup owns the exact must-list; seed from existing guidance and product docs, for example:

• Topology: not S1 for production; IDXC RF/SF at least production-like (skill table: RF 3 / SF 2 / ≥3 peers); dedicated CM (no CM-as-search); SHC when HA search is required.
• Secrets: no plaintext admin password in git; env / !vault / #52; never print secrets.
• TLS: web/management/S2S as required by the org; #69 when cert vault exists.
• Network: do not use the lab “open 22/8000 to 0.0.0.0/0” SG as production (#58).
• License: real entitlement, not trial-only; license_manager when required.
• Apps/config: persistent settings in splunk_config.yml (spa vs cup gate).
• Out of scope here: ingest sizing, hardware BOM, DR runbooks, CMHA until that ROADMAP row exists — document as “should / escalate”.

Verify (code)

Pick one primary gate (do not maintain three conflicting lists):

• Catalog (or YAML) is the source of must-keys; and
• spa validate --profile production (name at pickup) or deployment_intent: production in schema that fails on missing/unsafe settings (agent JSON: which rule, which key). Lab spa validate stays as today so examples still pass.

Tests: a fixture that is lab-valid and production-invalid; a fixture that passes the production profile (no real secrets in git — placeholders / vault refs only).

Related

• #53 catalog, #61 docs, #52 auth, #69 certs, #63 git/promote, #58 network groups

Notes

Pickup-ready enhancement. Skills call spa only. Never print secrets or bake production passwords/PEMs into the repo.

Start with the existing README, spa-create-config guidance, feature catalog, and AGENTS.md, then run the current spa validate path and inspect its schema and fixtures. Define the production profile and one validation gate, documenting its scope and references. Done means lab fixtures still pass, unsafe or missing production settings fail, and a production fixture passes without real secrets.