moose-inventory 2.0 → 2.1

data/docs/maintenance/database-backup-restore-guidance.md

@@ -0,0 +1,162 @@
+# Database backup and restore guidance
+
+Status: operational guidance for users; not an approval for destructive restore features.
+
+Moose Inventory supports SQLite, MySQL/MariaDB, and PostgreSQL database adapters. The CLI provides a direct `db backup` helper for SQLite only. Server-backed database engines should be backed up and restored with their native database tools and the user's normal operational controls.
+
+## Scope boundary
+
+Moose Inventory can:
+
+- report the configured adapter through `moose-inventory db status`;
+- run explicit ordered schema migrations through `moose-inventory db migrate`;
+- check expected schema/table state through `moose-inventory db doctor`;
+- copy the configured SQLite database file through `moose-inventory db backup FILE`;
+- export portable inventory snapshots for review, migration, and automation workflows.
+
+Moose Inventory does not currently:
+
+- run `mysqldump`, `mariadb-dump`, `pg_dump`, `pg_restore`, or server-specific restore commands;
+- manage database users, grants, TLS, server encryption, replication, point-in-time recovery, or retention policies;
+- guarantee transaction-consistent backups for server-backed databases;
+- implement destructive snapshot sync/restore semantics;
+- overwrite or drop user databases as a restore mechanism.
+
+Those operations belong to the database administrator, hosting platform, or user's backup system.
+
+## General backup principles
+
+For all adapters:
+
+1. Treat inventory databases, exported snapshots, audit output, and backups as sensitive infrastructure metadata.
+2. Back up before migrations, version upgrades, bulk imports, and manual database maintenance.
+3. Store backups outside the working directory if the repository may be shared.
+4. Protect backup files with filesystem, database, or object-storage access controls matching the source data sensitivity.
+5. Test restore procedures on a disposable database before trusting them for production recovery.
+6. Record the Moose Inventory version, database adapter, schema version, and source environment alongside backup evidence.
+
+Suggested pre-change evidence:
+
+```bash
+moose-inventory db status
+moose-inventory db doctor
+moose-inventory export snapshot ./backup/pre-change-inventory.yml
+```
+
+The snapshot is not a physical database backup. It is useful for review, migration, and reconstruction workflows, but it does not replace native database backups for server-backed engines.
+
+## SQLite
+
+SQLite is file-backed, so the CLI can provide a direct backup helper:
+
+```bash
+moose-inventory db backup ./backup/moose-inventory.sqlite3
+```
+
+Recommended SQLite restore pattern:
+
+1. Stop jobs or shells that may write to the SQLite database.
+2. Move the current database file aside rather than deleting it.
+3. Copy the backup into the configured database path.
+4. Run `moose-inventory db status` and `moose-inventory db doctor`.
+5. Inspect expected hosts/groups before resuming automation.
+
+Example manual restore outline:
+
+```bash
+cp ~/.moose/db/dev.db ~/.moose/db/dev.db.before-restore
+cp ./backup/moose-inventory.sqlite3 ~/.moose/db/dev.db
+moose-inventory db status
+moose-inventory db doctor
+```
+
+Do not restore over an active writer. If using SQLite in automation, pause the automation first.
+
+## MySQL and MariaDB
+
+Use native MySQL/MariaDB backup tooling such as `mysqldump` or `mariadb-dump`. Moose Inventory should not be the process that chooses dump options, credentials, locks, replication state, compression, encryption, or restore targets.
+
+Typical logical backup shape:
+
+```bash
+mysqldump \
+  --single-transaction \
+  --routines \
+  --triggers \
+  --databases moose_inventory \
+  > moose-inventory-mysql.sql
+```
+
+Notes:
+
+- Prefer credentials from a protected option file, environment-specific secret manager, or interactive prompt rather than committed config.
+- `--single-transaction` is appropriate for transactional tables such as InnoDB; confirm table engines before relying on it.
+- Capture grants/users separately if the restore target also needs database accounts and permissions.
+- For large deployments, consider physical backup, snapshots, or managed-service backup features instead of a logical dump.
+
+Recommended restore boundary:
+
+1. Restore into a new or disposable database first.
+2. Point a temporary Moose Inventory config at the restored database.
+3. Run `moose-inventory db status` and `moose-inventory db doctor`.
+4. Export and inspect a snapshot from the restored database.
+5. Cut over application configuration only after human review.
+
+Avoid restoring directly over the active database unless there is a separate incident/recovery plan and approval.
+
+## PostgreSQL
+
+Use native PostgreSQL backup tooling such as `pg_dump`, `pg_dumpall`, `pg_restore`, managed-service snapshots, or WAL/PITR tooling depending on the deployment.
+
+Typical custom-format logical backup shape:
+
+```bash
+pg_dump \
+  --format=custom \
+  --file=moose-inventory-postgres.dump \
+  moose_inventory
+```
+
+Typical inspection/restore shape for a disposable database:
+
+```bash
+createdb moose_inventory_restore_check
+pg_restore \
+  --dbname=moose_inventory_restore_check \
+  --clean \
+  --if-exists \
+  moose-inventory-postgres.dump
+```
+
+Notes:
+
+- Capture roles, ownership, and grants separately when needed; `pg_dump` of one database does not fully replace cluster-level role backup.
+- Use managed-service snapshot/PITR features when recovery-point objectives matter.
+- Keep connection strings, passwords, and dump files out of the repository.
+- Verify restore compatibility before upgrading PostgreSQL major versions or Moose Inventory schema versions.
+
+Recommended restore boundary is the same as MySQL/MariaDB: restore to a disposable database, verify with Moose Inventory read/status commands, then cut over only after human review.
+
+## Snapshot export/import and restore expectations
+
+`moose-inventory export snapshot` is a portable application-level export. It is useful for:
+
+- inventory review;
+- CI checks;
+- migration rehearsal;
+- emergency reconstruction when native DB backups are unavailable.
+
+Snapshot import remains additive/update-oriented. It is not a destructive restore or exact database rollback. A future destructive sync/restore mode would require separate requirements, UX design, recovery controls, tests, and explicit approval.
+
+## Release and maintenance checklist
+
+Before migrations, bulk import work, or release-adjacent database testing:
+
+- identify the adapter and environment;
+- run `moose-inventory db status` and `moose-inventory db doctor`;
+- create a SQLite backup or native server-backed database backup;
+- export a snapshot as review evidence;
+- test restore on a disposable target when risk warrants it;
+- document any destructive or externally managed restore action separately.
+
+If a backup or restore requires production credentials, cloud-console actions, database-account changes, or destructive replacement of an active database, stop and get explicit human approval.

data/docs/maintenance/package-maintenance-and-agent-boundaries.md

@@ -0,0 +1,260 @@
+# Moose Inventory Package Maintenance Runbook and AI-Agent Boundaries
+
+## Approval status
+
+Status: **Approved package maintenance and AI-agent operation-boundary baseline**
+
+Russ / Rusty Frink Desiato approved this document as the package maintenance and AI-agent operation-boundary baseline for Moose Inventory on 2026-05-29. Approval reference: `GOV-MAINT-001`.
+
+This document defines the routine package-maintenance runbook and AI-agent operation boundaries for Moose Inventory.
+
+Approved references:
+
+- `GOV-TAILOR-001`: Moose Inventory is approved as Class 4 with target profile Software Library / Package.
+- `GOV-PRODUCT-001`: `docs/product/product-brief.md` is approved as the product-framing baseline.
+- `GOV-REQ-001`: `docs/product/requirements-baseline.md` is approved as the requirements and acceptance criteria baseline.
+- `GOV-UX-001`: `docs/ux/cli-workflow-notes.md` is approved as the CLI UX/workflow baseline.
+- `GOV-ARCH-001`: `docs/architecture/architecture-and-trust-boundaries.md` is approved as the architecture and trust-boundary baseline.
+- `GOV-SEC-001`: `docs/security/security-privacy-process.md` is approved as the security and privacy process baseline.
+- `GOV-RISK-REG-001`: `docs/security/accepted-risk-register.md` is approved as the maintained accepted-risk register baseline.
+- `GOV-MAINT-001`: this document is approved as the package maintenance and AI-agent operation-boundary baseline.
+
+Related templates:
+
+- `docs/qa/qa-documentation-and-release-gates.md`
+- `docs/release/release-readiness.md`
+- `docs/release/publishing.md`
+- `docs/security/accepted-risk-register.md`
+
+Scope limit: this runbook covers local repository maintenance and release-readiness stewardship. It does not approve publishing a release, yanking/deprecating a gem, accepting risk, changing RubyGems/GitHub account ownership, adding hosted operations, or performing external communications as the project.
+
+## Maintenance principles
+
+- Keep maintenance boring. Boring is the grown-up version of secure.
+- Prefer small, reviewable branches with one intent each.
+- Keep generated files, local databases, coverage reports, temporary gems, and tool caches out of commits unless intentionally documented.
+- Use the full release gate before claiming release readiness.
+- Treat dependency, workflow, and release-infrastructure changes as supply-chain-sensitive.
+- Evidence is not approval. Tests, scans, and docs support human decisions; they do not replace them.
+
+## Routine maintenance cadence
+
+| Area | Suggested cadence | Evidence / command | Notes |
+| --- | --- | --- | --- |
+| Ruby dependencies | Monthly, before releases, and when advisories appear | `bundle outdated`, `bundle update <gem>` on scoped branches, `MOOSE_INVENTORY_REQUIRE_SECURITY_TOOLS=1 ./scripts/check.sh` | Prefer targeted updates over broad churn unless doing a planned dependency refresh. |
+| Ruby version support | Quarterly and before CI matrix changes | `.github/workflows/ci.yml`, gemspec Ruby requirement, local/CI gate | Changing supported Ruby versions is compatibility work and should be reflected in docs/release notes. |
+| GitHub Actions versions | Monthly or when deprecation/security notices appear | Review `.github/workflows/*.yml`, then full gate | Pin or upgrade actions deliberately; review permission and release-token implications. |
+| Security tools | Monthly and before releases | `scripts/ci/install_security_tools.sh`, `check_security.sh`, `check_secrets.sh` | If tool availability changes, update release-readiness docs and accepted-risk notes as needed. |
+| Vulnerability advisories | Before releases and when alerts arrive | OSV, `bundler-audit`, `osv-scanner`, GitHub advisory evidence when available | Triage reachability and severity; do not ship unresolved critical/high without explicit risk acceptance. |
+| Package metadata | Before releases and dependency bumps | `moose-inventory.gemspec`, `scripts/ci/package_sanity.sh` | Review executable, files, MFA metadata, dependency ranges, required Ruby, license, and homepage/source links. |
+| Release workflow and RubyGems publishing path | Before each release | `.github/workflows/release.yml`, `docs/release/publishing.md`, GitHub `release` environment status | Confirm trusted publishing assumptions before tagging. |
+| Documentation drift | After user-facing changes and before releases | Documentation QA checklist | Keep README, requirements, UX, architecture, security, QA, and release docs aligned. |
+
+## Standard maintenance workflow
+
+1. Start from a clean `master` branch.
+2. Create a focused branch for the maintenance item.
+3. Inspect the relevant docs, code, workflows, and backlog entries before editing.
+4. Make the smallest coherent change.
+5. Update docs and backlog records in the same branch when behavior, process, or risk posture changes.
+6. Run the smallest meaningful gate while developing.
+7. Run `MOOSE_INVENTORY_REQUIRE_SECURITY_TOOLS=1 ./scripts/check.sh` before merge when the work touches dependencies, package metadata, release tooling, security posture, or process evidence.
+8. Commit the branch work with a clear message.
+9. Merge back to `master` deliberately.
+10. Rerun the meaningful gate after merge.
+11. Report what changed, verification evidence, new backlog items, blockers, and whether `master` is clean/ahead of origin.
+
+## Dependency update runbook
+
+Use this for RubyGem dependency updates and dependency-range changes.
+
+1. Identify the reason for the update:
+   - vulnerability fix;
+   - compatibility with supported Ruby versions;
+   - routine maintenance;
+   - toolchain or CI support.
+2. Review current dependency constraints in `moose-inventory.gemspec`, `Gemfile`, and `Gemfile.lock`.
+3. Prefer a targeted update:
+
+   ```bash
+   bundle update <gem-name>
+   ```
+
+4. For security fixes, capture advisory identifiers and affected versions.
+5. Run:
+
+   ```bash
+   MOOSE_INVENTORY_REQUIRE_SECURITY_TOOLS=1 ./scripts/check.sh
+   ```
+
+6. Review whether package metadata or docs need updates.
+7. If a critical/high issue remains reachable, block release unless a human records accepted risk.
+8. Commit `Gemfile.lock` and any intentional constraint/doc updates together.
+
+Do not:
+
+- hide dependency warnings by weakening gates;
+- switch package sources without approval;
+- add network/runtime dependencies without architecture/security review;
+- broaden dependency ranges purely to silence tooling.
+
+## Ruby and CI action update runbook
+
+Use this when changing Ruby support or GitHub Actions dependencies.
+
+1. Review `.github/workflows/ci.yml`, `.github/workflows/release.yml`, `moose-inventory.gemspec`, and docs.
+2. For Ruby support changes, confirm the version is supported by required native/database gems.
+3. For action upgrades, review changelogs for permission, token, runtime, and behavior changes.
+4. Keep release workflow permissions minimal.
+5. Do not add publish secrets unless manual fallback is explicitly approved; trusted publishing/OIDC is the baseline.
+6. Run the full local gate and wait for CI evidence when pushed.
+7. Update release docs if release workflow behavior changes.
+
+## Vulnerability triage runbook
+
+Use highest applicable severity from `docs/security/security-privacy-process.md`.
+
+1. Capture the source:
+   - OSV/advisory ID;
+   - `bundler-audit` finding;
+   - `osv-scanner` result;
+   - GitHub security advisory;
+   - manual report.
+2. Identify affected component, version, and reachability:
+   - runtime dependency;
+   - development/test dependency;
+   - release workflow/tooling;
+   - documentation/example only.
+3. Determine impact:
+   - credential exposure;
+   - arbitrary code execution;
+   - data corruption/loss;
+   - package compromise;
+   - denial of service;
+   - process/tooling hardening gap.
+4. Choose disposition:
+   - fix immediately;
+   - patch dependency or workflow;
+   - document non-reachability;
+   - defer as backlog for low/medium findings;
+   - request accepted-risk approval when release would proceed with known risk.
+5. For suspected credential exposure or package compromise, stop release activity and escalate to a human maintainer.
+6. Record evidence in docs, backlog, or security notes as appropriate.
+
+Release blocking rule: unresolved critical/high findings block release unless an explicit human accepted-risk decision exists in `docs/security/accepted-risk-register.md`.
+
+## GitHub and RubyGems release-infrastructure stewardship
+
+Maintainers should periodically confirm:
+
+- repository owner/name remain `RusDavies/moose-inventory` for trusted publishing;
+- release workflow filename remains `release.yml`;
+- RubyGems trusted publisher uses the `release` environment;
+- GitHub `release` environment protection rules are understood before release;
+- workflow permissions remain least-privilege;
+- no RubyGems API key is stored in GitHub secrets for normal trusted publishing;
+- manual publishing credentials, if ever used, remain local, scoped, and protected with `0600` permissions.
+
+Agents may document observed configuration and prepare checklists, but changing GitHub/RubyGems account settings, repository ownership, trusted-publisher setup, secrets, or environment protections requires explicit human approval.
+
+## Release recovery runbook
+
+Use `docs/qa/qa-documentation-and-release-gates.md` for full yank/deprecation/rollback templates. Summary:
+
+1. Stop further release activity.
+2. Preserve evidence: version, tag, commit, workflow run, RubyGems URL, install output, and failure symptoms.
+3. Determine whether this is:
+   - ordinary regression;
+   - security issue;
+   - credential exposure;
+   - package compromise;
+   - publishing/workflow failure;
+   - RubyGems propagation false negative.
+4. If users are affected, prepare a patch release on a new version number.
+5. Do not yank, deprecate, publish an advisory, or manually push a gem without explicit human maintainer approval.
+6. Update release docs, accepted-risk register, audit notes, or backlog based on the outcome.
+
+## AI-agent permitted maintenance actions
+
+AI agents may perform these actions when working inside this repository and following the git workflow:
+
+- inspect repository files, docs, tests, and local git history;
+- create focused branches;
+- edit code, tests, docs, and process files for scoped tasks;
+- run local tests, linters, package sanity checks, security scans, and documentation checks;
+- update `BACKLOG.md` with discovered follow-up work;
+- add or update local runbooks, templates, and evidence docs;
+- commit and merge local branches after verification;
+- report status and evidence in the project Discord channel;
+- prepare release checklists, drafts, and recommendations.
+
+## AI-agent actions requiring explicit human approval
+
+Agents must ask first before:
+
+- pushing to remote branches or tags unless Russ explicitly requests it;
+- creating, moving, or deleting release tags;
+- publishing to RubyGems;
+- yanking or deprecating RubyGems versions;
+- changing RubyGems owners, trusted publishers, MFA settings, or package credentials;
+- changing GitHub repository settings, branch protections, release environment protections, secrets, deploy keys, or ownership;
+- adding/removing CI secrets or credentials;
+- accepting security/privacy/release risk;
+- making public security disclosures or advisories;
+- sending external communications as the project or maintainer;
+- introducing hosted-service behavior, telemetry, or new external network behavior;
+- deleting repository history or performing destructive cleanup beyond recoverable local temporary files.
+
+## AI-agent no-go zones
+
+Agents must not:
+
+- exfiltrate, print, commit, or store credentials;
+- bypass failed security checks by weakening gates without explicit review and approval;
+- treat proposed/monitored risks as accepted risks;
+- publish a release because checks passed;
+- use manual RubyGems credentials unless a human maintainer explicitly chooses that fallback;
+- modify account-level GitHub or RubyGems settings autonomously;
+- rewrite public history without explicit approval;
+- make legal/compliance claims beyond the approved docs;
+- represent the project as having hosted operations, RBAC, tenant isolation, telemetry guarantees, or compliance certifications not explicitly approved.
+
+## Maintenance report template
+
+```markdown
+## Maintenance report
+
+Item:
+Branch:
+Commit / merge:
+Date:
+
+Changed:
+- 
+
+Verification:
+- [ ] Small gate:
+- [ ] Full gate, if required:
+- [ ] Documentation reviewed:
+
+Risk / security notes:
+- Accepted-risk register changed: yes/no
+- New findings:
+- Human approvals required:
+
+Backlog:
+- New items added:
+- Burndown:
+
+Status:
+- `master` clean:
+- Ahead/behind origin:
+- Next recommended item:
+```
+
+## Current known operational follow-ups
+
+- Confirm GitHub `release` environment protection rules with maintainers before a future release.
+- Decide whether public `SECURITY.md` vulnerability intake should be added.
+- Complete destructive-command confirmation work before expanding destructive workflows.
+- Evaluate signed provenance or attestations later if target users require more than RubyGems trusted publishing.

data/docs/process/conformance-gap-analysis-2026-05-28.md

@@ -0,0 +1,192 @@
+# Moose Inventory Process Conformance Gap Analysis — 2026-05-28
+
+## Scope
+
+This analysis compares Moose Inventory against the updated workspace product-process guidance, especially:
+
+- `SOFTWARE_PRODUCT_DEVELOPMENT_PROCESS.md`
+- `TAILORING_GUIDE.md`
+- `GOVERNANCE_AND_APPROVALS.md`
+- requirements, architecture, security, QA, release, operations, and documentation guidance
+
+The key governance rule for this audit is explicit: **a document existing in the repository is evidence, not approval**. Approval requires a durable recorded decision with approver, date, scope, and limitations.
+
+## Recommended tailoring classification
+
+Recommended classification for approval: **Class 4 — Public / Production / Commercial Product**, target profile **Software Library / Package**.
+
+Rationale:
+
+- Moose Inventory is a public RubyGem published to RubyGems.
+- It is intended for real Ansible inventory workflows and can affect infrastructure operations.
+- It handles database configuration, environment-specific inventory state, package publishing, CI, and release automation.
+- It is not a hosted service or operated runtime, so the software-library/package target profile excludes normal service monitoring, alert routing, backup/restore operations, and runtime incident runbooks unless a future hosted/runtime component is added.
+- Library/package concerns remain mandatory: API/CLI compatibility, release integrity, trusted publishing, supply-chain security, vulnerability intake, security patching, maintainer ownership, and developer/user documentation.
+
+Approval status: **not approved**. This is a recommendation prepared for Russ or another authorized product owner to approve, revise, or reject.
+
+## Current evidence inventory
+
+| Area | Existing evidence | Approval status | Gap |
+| --- | --- | --- | --- |
+| Tailoring/classification | This analysis recommends Class 4 + Software Library/Package | Not approved | Need durable tailoring decision record |
+| Product framing | README explains purpose/use with Ansible | Not approved as product baseline | Need concise product brief/framing note with goals, users, non-goals, success criteria |
+| Requirements | README, CLI behavior, tests, backlog | Not approved as requirements baseline | Need requirements/acceptance baseline covering CLI, DB, Ansible integration, package/release, security, compatibility |
+| UX/product design | CLI help/README/tests | No UX approval | For CLI package, need lightweight CLI workflow/UX notes rather than wireframes |
+| Architecture | Code and README describe behavior; release docs cover publishing | Not approved | Need architecture overview for CLI/package, DB adapters, schema migrations, Ansible integration, trust boundaries, and release pipeline |
+| Security/privacy | Security audit reports, gitleaks/OSV/bundler-audit gates, README secret guidance, draft `docs/security/security-privacy-process.md`, draft `docs/security/accepted-risk-register.md` | Draft process evidence exists, not approved security/privacy baseline or risk acceptance | Need explicit review/approval of security/privacy baseline; future releases still need release-specific accepted-risk disposition |
+| Compliance readiness | Not applicable as enterprise product claim today | No compliance claims approved | Need explicit non-goal/claim boundary so no SOC 2/ISO/ISO-style readiness is implied |
+| Documentation planning | README and release docs exist | No documentation QA/sign-off record | Need documentation plan/checklist for user/developer/release/security docs |
+| QA/test evidence | `scripts/check.sh`, RSpec, SimpleCov, RuboCop, permission check, OSV, bundler-audit, gitleaks, package sanity, CI matrix | Test evidence exists per run, not process approval | Need QA plan mapping gates to requirements and release criteria |
+| Release security gate | Release readiness/publishing docs and security audits exist | No formal release approval template/current gate record | Need release-security gate checklist, accepted-risk disposition, release approval fields |
+| Operations/maintenance | Release docs, CI/release workflows, security audits | Partial | Need package-maintenance runbook: owner, release infrastructure, vulnerability intake, update cadence, release/yank/deprecation path, AI-agent maintenance boundaries |
+| AI-agent operation boundaries | Workspace/git workflow exists outside repo; no repo-local boundary | Not approved | Need repo-local boundaries for agent-assisted maintenance/release prep, especially no publishing/release/accepted-risk decisions without human approval |
+| Backlog/evidence practice | BACKLOG.md is extensive and current | Partial | Need process backlog acceptance criteria/approval notes on process items |
+
+## Gap analysis
+
+### 1. Governance and approvals
+
+The repository has strong implementation evidence but little explicit governance evidence. Release docs describe trusted publishing and successful v2.0 publishing, but they do not by themselves approve future releases, accepted risks, classification, or product direction.
+
+Gaps:
+
+- No recorded tailoring/classification approval.
+- No approval register or decision-record location specific to the repo.
+- No explicit list of human-owned decisions vs agent-executable maintenance work.
+- No accepted-risk register, even if currently empty.
+
+Impact: future agents can confuse “documented process” with “approved gate,” which is exactly the paper goblin we are trying not to feed.
+
+### 2. Product and requirements baseline
+
+README and tests provide a de facto behavioral contract, but there is no approved product/requirements baseline.
+
+Gaps:
+
+- No concise product brief stating target users, use cases, non-goals, and success criteria.
+- No requirements spec separating functional, non-functional, security, package/release, compatibility, and documentation requirements.
+- No explicit public API/CLI compatibility and deprecation policy beyond existing behavior/tests.
+
+Impact: development can continue, but release readiness and change impact rely on tribal knowledge plus tests rather than an approved baseline.
+
+### 3. CLI UX/workflow design
+
+Because Moose Inventory is a CLI/package, full visual UX wireframes are not needed. However, the updated process still expects workflow/usability/trust states where user-facing workflows exist.
+
+Gaps:
+
+- No lightweight CLI workflow/UX note for core workflows, destructive operations, dry-run behavior, machine-readable output, error states, accessibility/readability expectations, and trust/confirmation boundaries.
+- No UX approval record for CLI workflow conventions.
+
+Impact: output compatibility is well tested, but UX decisions are implicit.
+
+### 4. Architecture and trust boundaries
+
+The code has improved architecture, and release docs capture publishing mechanics, but there is no architecture overview matching the updated guidance.
+
+Gaps:
+
+- No architecture overview for CLI layers, operation objects, DB schema/migrations, adapters, Ansible plugin/shim integration, audit log, import/export, and release pipeline.
+- No data model/trust-boundary diagram or written equivalent.
+
+Impact: maintainers can infer architecture from code, but future maintainers/agents lack a clear evidence artifact.
+
+### 5. Security/privacy and vulnerability operations
+
+Security audit evidence is strong for recent work. The missing piece is not “did we scan?” but “what is the maintained security model?”
+
+Gaps:
+
+- Draft threat model/abuse-case, data classification/data-flow, secrets/logging, vulnerability intake/security patch policy, and accepted-risk register now exist under `docs/security/`.
+- These drafts are evidence, not approval. `GOV-SEC-001` must be approved, revised, or rejected before they become approved security/privacy process baseline.
+- Future releases still need release-specific accepted-risk disposition and release approval.
+- Secret scanning on GitHub is documented as unavailable/disabled in audit evidence; local gitleaks compensates, and the residual posture is tracked as a monitored proposed risk.
+
+Impact: current gates are good, but future security decisions lack durable process scaffolding.
+
+### 6. QA and documentation QA
+
+The automated gate is strong and repeatable. The process gap is mapping those checks to requirements/release criteria and documenting documentation QA.
+
+Gaps:
+
+- No QA plan that maps RSpec/SimpleCov/RuboCop/permission/security/package checks to release criteria.
+- No documentation QA checklist for README, release docs, examples, Ansible plugin docs, and security claims.
+- No known-issues/accepted-exceptions template for release candidates.
+
+Impact: checks are real, but release evidence is less reviewable than it should be.
+
+### 7. Release and package operations
+
+Trusted publishing and release docs are good. Updated guidance expects approval records, rollback/yank/deprecation plans, and post-release review.
+
+Gaps:
+
+- No formal release checklist template with approver/date/scope/conditions.
+- No release security gate template/current gate record.
+- No explicit gem yank/deprecation/rollback decision path.
+- No post-release review template or cadence.
+
+Impact: publishing mechanics are documented, but release governance is incomplete.
+
+### 8. Operations profile for a library/package
+
+Moose Inventory does not need hosted-service monitoring, alerting, backup/restore, or runtime incident operations unless it later ships an operated service. It does need package maintenance operations.
+
+Gaps:
+
+- No maintainer operations runbook for dependency update cadence, vulnerability triage, CI/release failures, RubyGems/GitHub account stewardship, trusted publishing maintenance, and release recovery.
+- No AI-agent operation boundaries for repository maintenance and release preparation.
+
+Impact: routine maintenance remains doable, but not yet process-conformant under the updated package-maintenance and AI-agent guidance.
+
+## Proposed remediation plan
+
+### Phase 1 — Governance baseline and tailoring
+
+1. Create `docs/governance/approval-register.md` or equivalent.
+2. Record proposed Class 4 + Software Library/Package tailoring decision as **pending approval**.
+3. Define human-owned decisions: product direction, release approval, accepted risks, RubyGems publishing, compliance/public claims, destructive repo/package actions.
+4. Define agent-executable work: local docs/code/test changes, evidence gathering, draft release notes/checklists, non-public internal backlog work.
+
+Exit criteria: Russ or delegated approver explicitly approves or revises the tailoring decision.
+
+### Phase 2 — Product and requirements baseline
+
+1. Add a concise product brief.
+2. Add requirements/acceptance criteria for CLI behavior, DB backends, Ansible integration, import/export, dry-run/plan, audit log, release/package integrity, compatibility, and documentation.
+3. Mark requirements as draft until approved.
+
+Exit criteria: requirements baseline approved or explicitly left draft with blockers tracked.
+
+### Phase 3 - Architecture, security, and trust boundaries
+
+1. Add architecture overview and data/trust-boundary notes.
+2. Add threat model/data classification/secrets-handling notes.
+3. Add vulnerability intake/security patch policy and accepted-risk register.
+
+Exit criteria: architecture/security baseline reviewed; unresolved risks tracked.
+
+### Phase 4 — QA, documentation, and release gates
+
+1. Add QA plan mapping current `scripts/check.sh` gates to process expectations.
+2. Add documentation plan and documentation QA checklist.
+3. Add release checklist and release security gate template with approval fields.
+4. Add package rollback/yank/deprecation path and post-release review template.
+
+Exit criteria: next release can produce a complete evidence packet without reconstructing process from commit history and vibes.
+
+### Phase 5 — Maintenance/agent boundaries
+
+1. Add package maintenance runbook.
+2. Add AI-agent operation boundaries for repo maintenance, release prep, and explicit no-go zones.
+3. Add maintenance cadence reminders/backlog items for dependencies, Ruby versions, CI actions, security scans, and docs review.
+
+Exit criteria: maintainers and agents can safely inspect, patch, prepare releases, and know when to stop for human approval.
+
+## Current launch/release posture
+
+Moose Inventory has strong automated verification and trusted-publishing evidence, but under the updated process it is **not process-conformant for a future release** until at least tailoring, release approval, accepted-risk disposition, documentation QA, and release-security gate evidence are recorded for that release.
+
+This does not invalidate prior releases; it identifies the gap between current repository evidence and the updated workspace process baseline.