cwp coverage

cwp coverage [env] [flags]

Acts on the local site. Name an environment to act there instead.

Argument	What it is	Default
[env]	environment to census (default: default_environment in cwp.yml)

Flag	What it does	Default
--baseline <file>	a census recorded against a default install, so options can be judged
--against <env>	census another environment and compare option by option
--suggest	print only the settings: block for the prefixes worth carrying	off
--with-agent	with —dry-run on a host with no shell: install and remove the PHP agent so the plan is real	off

Plus the shared flags --json, -v, --verbose, -q, --quiet and --dry-run.

What it does

Counts what WordPress holds, area by area, against what the committed tree describes, and names the difference.

The tree describes a site through six artifacts: the content tree, the design system, settings/, widgets/, roles.yml and inventory.yml. A WordPress install holds state that none of them reaches. Post types and taxonomies nothing declares. Options nobody has put in a group. Custom tables. So a second machine can check the repository out, build it, and produce a site that is not the same one. Every column of cwp status reads green all the while, and correctly so.

status compares what an artifact describes. This command asks what no artifact describes at all. So it names an environment and reads the tree, and moves nothing between them.

Each area gets one of four verdicts:

Verdict	What it means
tracked	an artifact describes it, and cwp status compares that artifact
excluded	nothing describes it and that is a decision: the scrub deletes it, it is personal data, or it is a table the page builder declares as a log
untracked	nothing describes it and something could. This is the working list
not-reproducible	nothing describes it and nothing in this tool will. Custom tables

Options are grouped by whoever owns them

Four hundred untracked options is a number, not a finding. Almost every one belongs to something installed, and the inventory already records enough to derive the namespace. So the report groups the option area by prefix and attributes each prefix to the plugin or theme that owns it, with a count of how many of its options somebody has set.

A prefix with options and no installed owner is the residue of a plugin somebody removed. The report names it, and only names it: nothing here deletes an option.

--suggest prints a features: line for every family that is available, then a settings: block for the remaining prefixes worth carrying. A comment on each line says where it came from. It is a suggestion to review, never a write: which of a plugin’s options are decisions and which are runtime state is a judgement about that plugin.

Owners and families, across the areas

Each area gets its own verdict, and a feature that lives in two areas gets two. A plugin whose post type the tree carries and whose options it does not reads tracked twice. So the report asks the question once more at the level that has one answer: per owner, and per family.

  owner                   post types   taxonomies   options   verdict
! theme example-child     1/1          0/0          0/31      half carried
  example-child: options example_*

half carried is the verdict the area rows cannot give. An owner of which the tree holds everything has no row here.

A family is one feature of a plugin with every place it keeps state, switched on under features: in cwp.yml (the cwp.yml reference has the file it reads from). One row per family, every member counted, and one line per gap:

  family                  mode   options   post types   post meta   term meta   asserts   settle       verdict
✓ example-child/seo       on     29/29     –            1/1         1/1         2/2       1 recorded   tracked
! example-child/redirects on     –         1/1          –           –           –         2 recorded   half carried
  example-child/redirects: options not pulled yet: cwp pull --only settings
  example-child/logs      available

available is a family a file knows for an owner the inventory lists and features: does not name. settle counts the steps the family names for the target after its data lands. The census records them until they travel with the family. The census judges an assert against the side’s value, and checks a per-type map for every post type the tree carries.

Meta keys nothing decides

For every post type the tree manages, the census counts the meta keys its posts carry. It judges each by the group’s meta.include and meta.exclude. The ones neither names are the finding: the pull skips an undecided key and says nothing.

  post type   key                 posts   rule   verdict
! page        _example_seo_title  12      –      undecided
! page        _old_builder_field  20      –      undecided

Name each under the group’s meta.include or meta.exclude. The census reads keys only, never a value.

Judging an option needs a second side

Without one, the report counts options and judges none of them, and says so. Two ways to give it one:

• --baseline <file> — a census recorded against a default install. Record one with cwp coverage --json and keep the file.
• --against <env> — census another environment live and compare option by option. This is the fastest answer to what does that machine have that this one does not.

The census never reads an option value out. An option travels through the census as a name, a byte length and a hash of its value. That makes it safe to run against production and safe to keep the output.

What it does not do

• It closes no gap. It measures. Carrying settings, roles and widget areas into the tree is cwp pull, one artifact at a time with --only or all of them at once. The report says which of them a given project needs.
• It writes nothing to cwp.yml. Not the post types it finds, not the option prefixes. A generated declaration is a judgement made silently.
• It does not read table contents. It counts and names a custom table, never dumps it. Exporting one would be a database push behind the tool’s back, which the direction rule forbids.
• It does not delete anything, including options belonging to plugins that are no longer installed.
• It makes no claim about personal data. It reports what the scrub removes as excluded with that reason. Its opinion ends there.