Review Summary

This PR adds well-designed CLI commands for managing trusted collectives (swamp extension trust list/add/rm/auto-trust), solving an important discoverability problem.

No Blocking Issues

The PR follows all project requirements and patterns correctly.

Architecture (DDD Compliant)

The architecture properly follows the libswamp + renderer pattern:

Code Quality

• Named exports throughout (no default exports)
• All files include AGPLv3 copyright headers
• CLI commands correctly import from src/libswamp/mod.ts
• Input validation on collective names (/^[a-z0-9][a-z0-9_-]*$/) prevents malformed input
• Proper error handling with SwampError types
• The AnyOptions pattern is consistent with 68+ existing CLI commands

Test Coverage

All new source files have corresponding test files:

• 5 generator test files in src/libswamp/extensions/
• 3 renderer test files in src/presentation/renderers/
• Tests cover happy paths, error cases, and edge cases (empty arrays, defaults, deduplication)

Documentation

Good updates to design docs and 7 skill files for discoverability.

Note on DDD Ratchet

The bump from 43 to 46 KNOWN_PRESENTATION_INFRA_VIOLATIONS is appropriate - the new renderers use writeOutput from infrastructure following the existing pattern.

Adversarial Review

I've systematically traced code paths, examined edge cases, and stress-tested error handling across all changed files. This is a well-structured PR that follows the libswamp + renderer pattern consistently.

Critical / High

None found. The code is solid.

Medium

1. Race condition in read-modify-write (theoretical) — trust_add.ts:64-87, trust_rm.ts:52-75, trust_auto_trust.ts:60-72

   All three generators follow a read-modify-write pattern without locking:

   const marker = await deps.readMarker();
   // ... modify marker.trustedCollectives ...
   await deps.writeMarker(marker);

   Breaking scenario: Run swamp extension trust add orgA and swamp extension trust add orgB concurrently. Both read the same initial state, both append their collective, and whichever writes last wins — the first addition is lost.

   Severity: Medium because (a) atomic write prevents corruption, only data loss, (b) concurrent CLI invocations of the same command are rare in practice, (c) the effect is limited to trust configuration, not critical data.

   Suggested fix: Not required for merge. If ever needed, use file locking or optimistic concurrency (read version, fail if changed).

Low

1. @ prefix in collective name causes confusing error — trust_add.ts:27,54-62

   Users familiar with extension types (@swamp/model) might input swamp extension trust add @myorg. The validation error says "Must match [a-z0-9][a-z0-9_-]*" but doesn't explain that collective names don't use the @ prefix.

   Example: swamp extension trust add @acme → error about regex, user confused

   Suggested fix: Add a specific check for leading @ with a clearer message: "Collective names don't include the '@' prefix. Use 'acme' instead of '@acme'."

2. Infrastructure exceptions bubble up raw — trust_add.ts:87, trust_rm.ts:75, trust_auto_trust.ts:72

   If writeMarker throws (disk full, permission denied), the raw Deno exception propagates to the user rather than a SwampError. This produces less consistent error messaging compared to validation errors.

   Example: Deno.errors.PermissionDenied: permission denied instead of "Failed to update .swamp.yaml: permission denied"

   Suggested fix: Wrap writeMarker in try/catch and yield an error event with a user-friendly message. Not blocking since atomic write prevents partial state.

Verdict

PASS — No blocking issues found. The code is well-tested (50 new tests), follows established patterns, and handles the common paths correctly. The race condition is theoretical for a CLI tool, and the UX improvements in Low findings are polish, not correctness issues.