compliance-baseline-deploy

What this skill does

# Compliance Baseline Deploy (Full Rule Set)

Deploys the FULL recommended rule baseline for a compliance framework — D&R rules, FIM rules, artifact-collection rules, and exfil rules — to a single LimaCharlie organization. Human-in-the-loop with explicit confirmation; defaults to dry-run.

This is the "I subscribed and want the rules in my org" path. For the case-reviewer agent (separate concern), use `compliance-deploy`. For a gap report, use `compliance-gap`. For a single control lookup, use `compliance-lookup`.

## When to invoke

- Customer has just installed `lc-compliance` and wants the framework's rules deployed for the first time
- Refreshing the deployed baseline after the bundled implementation doc has been updated
- A net-new org being prepared for an audit window

If the user only wants a subset (e.g., for a demo), redirect them to `compliance-deploy --with-rules`, which deploys ~10 representative rules. This skill is for the full set (50–110+ rules per framework).

## Argument parsing

Expected: `<framework> [--oid <oid>] [--apply] [--overwrite] [--kinds <list>]`

| Framework shorthand | Resolved |
|---|---|
| `pci`, `pci-dss` | pci-dss |
| `nist`, `800-53`, `nist-800-53` | nist-800-53 |
| `cmmc` | cmmc |
| `hipaa` | hipaa |
| `soc2` | soc2 |
| `iso`, `iso-27001` | iso-27001 |
| `cis`, `cis-v8` | cis-v8 |

- `--oid` defaults to the CLI's current org. If no org is set, ask the user.
- `--apply` — required to actually write to the org. Without it, the skill produces a deploy plan and stops.
- `--overwrite` — replace rules that already exist under the same name. Without it, existing rules are SKIPPED (default).
- `--kinds` — comma-separated subset of `dr,fim,artifact,exfil` (default: all four). Useful when an extension is missing (e.g., skip `fim` if `ext-integrity` is not subscribed).

## Locating bundled assets

All framework reference docs ship inside this plugin under `${CLAUDE_PLUGIN_ROOT}/compliance/<framework>/`. Throughout this skill, paths written as `compliance/<framework>/...` resolve to `${CLAUDE_PLUGIN_ROOT}/compliance/<framework>/...`.

If `${CLAUDE_PLUGIN_ROOT}` is not set, derive the plugin root from this skill's base directory (`<base>/../..`), or fall back to:

```bash
find / -path "*/lc-compliance/.claude-plugin/plugin.json" 2>/dev/null | head -1 | xargs dirname | xargs dirname
```

## Pre-flight checklist

Before assembling the deploy plan, confirm the org has the extensions each rule kind requires. The reliable probe is `extension schema` — it succeeds only when the extension is subscribed AND the org's extension subscription record is healthy. `extension list` is NOT a reliable probe: it shows extensions whose hive records exist even when the underlying subscription is incomplete on a brand-new org.

| Rule kind | Required extension | How to check |
|---|---|---|
| `dr` (D&R rules) | none — built-in | always available |
| `fim` (FIM rules) | `ext-integrity` | `limacharlie --oid <oid> extension schema --name ext-integrity --output yaml` (succeeds = subscribed) |
| `artifact` (artifact collection) | `ext-artifact` | `limacharlie --oid <oid> extension schema --name ext-artifact --output yaml` |
| `exfil` (exfil routing) | `ext-exfil` | `limacharlie --oid <oid> extension schema --name ext-exfil --output yaml` |

If `extension schema` errors with `failed to get extension <name>: ... no such entity`, the extension is not subscribed. In that case, do NOT silently skip — surface the gap to the user and ask whether to:
1. Skip that kind for this run (`--kinds` excludes it)
2. Have the user subscribe via `limacharlie --oid <oid> extension subscribe --name <ext-name>` and re-run

> **Note on paid resources.** Some extensions (`ext-integrity`, `ext-exfil`, `ext-artifact`) are gated by paid LC resources (`replicant/integrity`, `replicant/exfil`, `replicant/logging`). The `extension config-set` API used by this skill stores rules regardless of paid-resource state — but the rules will not *fire* until the resource is active. Configuration storage and rule firing are separately gated, so DO NOT block the deploy on paid-resource subscription. If you want to detect this for a warning, the legacy commands `integrity list` / `exfil list` / `logging list` return `org not registered to service` when the paid resource is inactive (and they are otherwise unused by this skill).

## Workflow

### Step 1 — Resolve framework and load the baseline

```bash
# Read the canonical baseline
cat "${CLAUDE_PLUGIN_ROOT}/compliance/<framework>/recommended-rules.yaml"
```

Extract the four lists from `recommended.`: `dr_rules`, `artifact_rules`, `fim_rules`, `exfil_rules`. Capture the counts from `counts:` for the plan summary.

### Step 2 — Extract each rule's YAML from the implementation doc

The bundled implementation doc has the deployable YAML for every rule, fenced with ` ```yaml ... ``` `. Two block shapes appear:

| Shape | Identifying field | Examples |
|---|---|---|
| **D&R rule** — top-level `name:`, `detect:`, `respond:` | `detect:` and `respond:` keys | `pci-10-failed-logon-windows` |
| **Rule-map entry** — single-key map whose value is a dict with `patterns:` / `events:` / paths | top-level key matches the rule name | `pci-wel-security`, `pci-fim-windows-audit-logs`, `pci-windows-events` |

For each rule name in the baseline:

1. Search the impl doc for a YAML fence that begins with `name: <rule-name>` (D&R) OR `<rule-name>:` at the start of a fenced block (rule-map kinds).
2. Capture the YAML inside the fence verbatim.
3. If a rule name in `recommended-rules.yaml` has no matching block in the impl doc, flag it — never invent or fill in a placeholder.

### Step 3 — Query the org for currently-deployed state

All three of the non-D&R kinds live in the `extension_config` hive — read them via `extension config-get`, NOT via `integrity list` / `exfil list` / `logging list` (those commands target a legacy service path that returns `org not registered to service` on modern orgs even when rules are deployed). The `hive get --partition-name` form referenced in older guidance does not exist on the current CLI.

```bash
# D&R rules currently in the general namespace
limacharlie --oid <oid> dr list --namespace general --output yaml

# FIM rules — read from ext-integrity config (data.fim_rules)
limacharlie --oid <oid> extension config-get --name ext-integrity --output yaml 2>/dev/null

# Artifact rules — read from ext-artifact config (data.log_rules)
limacharlie --oid <oid> extension config-get --name ext-artifact --output yaml 2>/dev/null

# Exfil rules — read from ext-exfil config (data.exfil_rules.list)
limacharlie --oid <oid> extension config-get --name ext-exfil --output yaml 2>/dev/null
```

If any `extension config-get` call returns `RECORD_NOT_FOUND`, treat that kind as having zero deployed rules (the extension is subscribed but no config record exists yet — that's a clean slate, not an error).

Build a set of currently-deployed rule names per kind. Anything in the deployed set whose name does NOT appear in the recommended baseline is "deployed extra" and stays untouched.

For exfil specifically: orgs commonly ship with default rules (`default-chrome`, `default-linux`, `default-macos`, `default-windows`). These count as "deployed extras" and MUST be preserved on update — see Step 6.

### Step 4 — Compute the deploy plan

For each kind in {dr, fim, artifact, exfil}:

| Bucket | Action |
|---|---|
| In recommended, not deployed | **ADD** — push to org |
| In recommended, deployed under same name | **SKIP** (default) or **UPDATE** if `--overwrite` |
| Deployed extra (not in recommended) | **LEAVE ALONE** — not this skill's concern; reported as informational |
| In recommended, no YAML block found in impl doc | **HALT** — surface to user; do not proceed |

### Step 5 — Show the plan to the user

Print a structured plan, even in `--apply` mode. Required, do not skip:

```
# Compliance Baseline Deploy Plan

**Framework:** PCI DSS v4.0
**Org:** <oid>