Upstream Coverage Ledger

The feature map says what Hermes and Honcho behavior means in Go. This ledger answers the harder question: how do we know the map is complete?

Gormes does not claim completeness by vibes or by a long prose essay. A planner pass can claim a mapped upstream only when every feature-bearing upstream source class below has a feature-map anchor, a Go target, and either a concrete progress.json row or an explicit owned/excluded decision.

Completeness Standard

A Hermes or Honcho surface is mapped only when all five checks pass:

1. Inventory: the upstream file, directory, endpoint group, SDK surface, or public document belongs to a row in this ledger.
2. Feature-map anchor: the row links to a section in Hermes And Honcho Feature Map.
3. Go target: the row names a Gormes package, command, doc surface, or an intentional Go-native replacement.
4. Backlog reachability: incomplete behavior has a progress.json anchor; broad anchors stay non-builder-ready until split.
5. Drift rule: new upstream feature-bearing files must update this ledger, the feature map, and progress.json in the same planner pass.

The status vocabulary is the same as the feature map: covered, planned, vague, missing, owned, and excluded. Excluded is allowed only for upstream repo hygiene, release notes, generated assets, or examples that do not change public runtime behavior.

Audit Commands

Use these commands during a full parity pass. They intentionally inventory source classes, not vendored caches or Git metadata:

find ../hermes-agent -type f \
  \( -name '*.py' -o -name '*.md' -o -name '*.json' -o -name '*.yaml' -o -name '*.yml' -o -name '*.toml' -o -name '*.lock' -o -name '*.nix' -o -name '*.sh' -o -name 'Dockerfile' -o -name 'docker-compose.yml' \) \
  ! -path '*/.git/*' ! -path '*/node_modules/*' ! -path '*/__pycache__/*' \
  | sed 's#^../hermes-agent/##' | awk -F/ '{print $1}' | sort | uniq -c

find ../honcho -type f \
  \( -name '*.py' -o -name '*.md' -o -name '*.mdx' -o -name '*.ts' -o -name '*.tsx' -o -name '*.json' -o -name '*.yaml' -o -name '*.yml' -o -name '*.toml' -o -name '*.lock' -o -name '*.ini' -o -name '*.sh' -o -name 'Dockerfile' \) \
  ! -path '*/.git/*' ! -path '*/node_modules/*' ! -path '*/__pycache__/*' \
  | sed 's#^../honcho/##' | awk -F/ '{print $1}' | sort | uniq -c

If either command shows a new feature-bearing class that is not represented below, the map is no longer complete.

Executable Check

go test ./docs -run TestUpstreamCoverageLedgerMatchesSourceClasses -count=1 compares this ledger against the local sibling ../hermes-agent and ../honcho checkouts when they are present. The test fails when a feature-like top-level source class is neither represented in this ledger nor explicitly classified as repo hygiene. It skips a missing sibling checkout so normal docs CI does not require cloning upstream repos.

This is necessary but not sufficient for feature parity. Use Hermes/Honcho To Gormes Go Runtime Plan for the reconciled subsystem classification and Go implementation order. Use Swarm Feature Parity Audit for nested feature-level gaps found inside broad source classes such as agent/**, tools/**, gateway/**, src/**, sdks/**, mcp/**, and tests/**. Use TestNestedUpstreamFeatureCoverage to make representative nested paths executable when sibling upstream checkouts are present.

Hermes Source Coverage

Honcho Source Coverage

What Counts As Unmapped

An upstream feature is unmapped when any of these are true:

• its source class is absent from this ledger;
• its ledger row points to no feature-map section;
• the feature map names no Go target or intentional divergence;
• incomplete behavior has no progress.json row;
• a row exists but has no source_refs, write_scope, test_commands or no_test_required, acceptance, and done signal.

When that happens, the correct action is a gormes-parity-auditor pass followed by a gormes-planner pass. Do not hand the behavior to gormes-builder until the map and row are builder-ready.