Correctness sub-agent should verify config struct field propagation across adapter serialization paths

[fullsend-ai-retro]

What happened

On PR #5826, the author added a PerOrgForeignCompat field to WorkerConfig in internal/mintcore/config.go and wired it through the Go handler and GCF embed paths. However, the Cloudflare Worker TypeScript adapter (internal/dispatch/cf/workersrc/src/index.ts) was not updated to serialize the new field into configJSON, meaning PER_ORG_FOREIGN_COMPAT could never take effect on CF Worker deployments.

The fullsend review agent ran 7 successful passes (run 30740852332 through run 30804870826) and reviewed both config.go and index.ts but never flagged the missing field propagation. qodo-code-review caught the bug at "Action required" severity with a specific fix, and the author fixed it in commit 833d11f.

This repo has a recurring pattern of config field propagation gaps: fullsend#5808 (defaults.auto_merge parsed but never consumed) and fullsend#5354 (AllowedDomains not propagated to FetchPolicy) document similar bugs.

What could go better

The review correctness sub-agent lacks guidance for a specific high-impact pattern: when a config struct gains a new field, verify that all serialization and deserialization paths — including cross-language adapter implementations — include the field. This is distinct from the general cross-file impact analysis gap (fullsend#1525) because it targets a concrete, enumerable pattern rather than an open-ended consumer trace.

It is also distinct from agents#455 (code agent struct consumer enumeration), which targets proactive implementation planning in the code agent. This proposal targets reactive verification in the review agent — a safety net for when the code agent or human author misses a consumer.

I am confident this is a real gap because: (a) the review agent reviewed both the Go config struct and the TypeScript adapter across 7 runs without connecting them, (b) the repo has at least 2 other open bugs with the same root cause, and (c) the bug was on a security-critical feature where silent failure has material consequences.

Uncertainty: I have not read the correctness sub-agent's full skill file to verify whether cross-language adapter checking is already mentioned but ineffective (a prompt quality issue) versus completely absent (a coverage gap). The agents repo discovery shows the skill is at skills/code-review/SKILL.md in fullsend-ai/agents.

Proposed change

Add config-struct field propagation guidance to the correctness sub-agent skill (skills/code-review/SKILL.md in fullsend-ai/agents). When reviewing a PR that adds or modifies fields on a config/settings struct:

1. Identify all constructor paths that initialize the struct (e.g., NewHandler, NewHandlerFromConfig, ParseWorkerConfig).
2. Identify all serialization/deserialization sites — including cross-language adapters (e.g., TypeScript Workers, Python scripts) that convert the struct to/from JSON, environment variables, or wire formats.
3. Verify the new field appears in every path. Flag any path that omits it as a medium-severity finding.

This should be framed as a checklist heuristic, not a hard rule, to avoid false positives on intentionally partial serialization (e.g., fields marked json:"-").

Validation criteria

On the next 3 PRs to fullsend-ai/fullsend that add a field to a config struct in internal/mintcore/ or internal/config/, the review agent should either (a) confirm all serialization paths include the new field, or (b) flag any path that omits it. Measure by comparing fullsend-ai-review findings against qodo and human findings on the same PRs — the field-propagation gap should be closed (zero instances where another reviewer catches a missing field that fullsend-ai-review missed).

---

Generated by retro agent from fullsend-ai/fullsend#5826

[fullsend-ai-prioritize]

RICE Priority Score: 3.6

Score breakdown

Dimension	Score	Reasoning
Reach	1.5	The review agent runs on all PRs in the fullsend repo, and config struct field propagation is a recurring pattern — the issue documents at least 3 known instances (PRs #5826, #5808, #5354). All users relying on the review agent for correctness checking on config-touching PRs are affected, spanning multiple customers/projects.
Impact	1.5	Missing config field propagation causes silent failures where new config options don't take effect on certain deployment paths. The issue notes this specific case was on a security-critical feature. However, the review agent is a safety net (other reviewers like qodo and humans can still catch these), so the impact per affected user is a significant pain point rather than a complete blocker.
Confidence	0.8	High confidence. The issue is exceptionally well-written with concrete examples, a clear proposed change (add checklist to a skill file), specific validation criteria, and documented prior art of the same bug pattern recurring. The only uncertainty is whether the guidance is absent vs. present-but-ineffective in the current skill file, which the author acknowledges.
Effort	0.5	The proposed change is adding a checklist heuristic to a single skill file (skills/code-review/SKILL.md). The issue provides the exact 3-step checklist to add. This is a well-scoped prompt/guidance change, not an architectural or code change.

Formula: (1.5 x 1.5 x 0.8) / 0.5 = 3.6