Unify per-feature *-wire.ts activation behind one shared resolver

[JSONbored]

Context

Part of the review-stack architecture audit (parent epic — config-sprawl dimension). This is the
single highest-impact finding in the config-sprawl audit — it has already caused a real production
incident and directly blocks the "reuse the existing config plumbing for a future hosted version" goal.

The problem

There isn't one config-resolution system for advisory review capabilities; there are at least five,
independently implemented, with different precedence per feature.

The "canonical" path is resolveRepositorySettings (src/settings/repository-settings.ts:34) →
resolveEffectiveSettings (src/signals/focus-manifest.ts:496), which correctly implements
.gittensory.yml > DB > defaults for the 102 fields of RepositorySettings. That part is solid.

But a family of ~16 src/review/*-wire.ts modules gate advisory review capabilities (RAG, reputation,
unified comment, safety defang, grounding, e2e-test-gen, screenshots, inline comments, fix-handoff,
impact map, culture profile, review memory, content lane, selftune, …) through their own, separately-
coded activation logic that sits entirely outside RepositorySettings/resolveEffectiveSettings. At
least four distinct precedence shapes exist:

• Shared function resolveConvergedFeature (src/review/feature-activation.ts:48) for 6 features
  (rag/reputation/unifiedComment/safety/grounding/e2eTests): env kill-switch AND (yml features.X
  override OR GITTENSORY_REVIEW_REPOS allowlist fallback), with safety/grounding asymmetrically
  clamped.
• src/review/visual-wire.ts:24 (screenshots): env flag AND allowlist only — screenshots is
  not even a ConvergedFeatureKey, so it has no .gittensory.yml features: override at all, unlike
  its 6 siblings documented right next to it in .gittensory.yml.example:1092-1098.
• src/review/impact-map-wire.ts, review-memory-wire.ts, repo-culture-profile-wire.ts: env flag
  AND a .gittensory.yml review.X toggle only — no allowlist role whatsoever.
• src/review/inline-comments.ts:43, fix-handoff.ts: env flag AND explicit yml toggle only, with
  comments explicitly noting the allowlist "no longer applies to this feature" — a documented behavior
  change from an earlier, different precedence.

A self-hoster who sets review.impact_map: true has no way to know they also need
GITTENSORY_REVIEW_IMPACT_MAP=true set at the deployment level, while a self-hoster who sets
features.screenshots: true (a natural guess given the six sibling keys right there in the example)
will find it silently does nothing, because screenshots activation is env+allowlist only. Each
-wire.ts file documents its own rule accurately in isolation, but there is no single place that tells
an operator "here is the one true way every feature gets turned on."

Already caused a real incident

src/env.d.ts:376-386 documents that GITTENSORY_REVIEW_REPOS and GITTENSORY_PUBLIC_STATS_REPOS
"once held the same value," and a past reuse of the review cutover allowlist for the public stats
allowlist meant that correctly emptying GITTENSORY_REVIEW_REPOS (after those repos moved to self-host)
silently zeroed the unrelated public homepage counter too.

Fix

Consolidate the *-wire.ts activation checks behind one shared resolver — extend
resolveConvergedFeature to cover all per-PR advisory features, including
screenshots/impact-map/memory/culture-profile/inline-comments/fix-handoff, with one documented
precedence rule and named, per-feature exceptions only where security actually requires asymmetry
(safety/grounding already show this is doable).

Acceptance criteria

• All ~16 advisory-feature activation checks route through one shared resolver with one documented
  precedence rule.
• Every feature in .gittensory.yml.example's features: block behaves identically re: what
  overrides what (yml vs env vs allowlist).
• No behavior change for any repo's current effective feature set (verify against current production
  config before/after).
• This is the flagship reuse target for a future hosted/multi-tenant version — design the shared
  resolver so per-tenant config could plug in without a second rewrite.

Given the size (16 call sites across distinct features), expect multiple sequential PRs.

[linear-code]

JSO-3388

[JSONbored]

First tranche shipped: PR #4692 adds the shared resolveFeatureActivation core (4 named precedence modes: standard/forceOnOnly/allowlistRequired/manifestOnly) and migrates 6 of ~16 features onto it: screenshots (promoted to a full ConvergedFeatureKey — this is the fix for the issue's clearest gap, no features: override existed for it before), impactMap, reviewMemory, inlineComments, fixHandoff, cultureProfile.

Verified independently: the standard-mode formula (override ?? allowlisted) is algebraically identical to the old if (override !== null) return override; return allowlisted for every existing repo config (backward-compatible by construction, since no repo could have set features.screenshots before this PR — the field didn't exist). forceOnOnly/allowlistRequired are literal copies of the pre-existing safety/grounding asymmetric branches. Old test suite preserved unchanged (re-pointed at the new function), new tests added for the override behavior that didn't exist before.

Deliberately deferred (disclosed in the PR, reasoning given for each): contentLane (already matches standard precedence, just not literally wired through — lower priority), selftune (base eligibility is isAgentConfigured, not an allowlist — doesn't fit either adapter without a bigger redesign), enrichment/ops/outcomes/parity-audit/maintainer-recap (deployment-level concerns, never had a per-repo toggle), issue-rag-wire.ts (not an activation file at all).

Remaining scope for a fast-follow: migrate contentLane onto the shared resolver, and design the selftune case properly rather than leaving it out.

[JSONbored]

Verified all 4 first-target features against live source (not just this issue's own summary) and found real additional complexity worth recording before anyone starts implementation — including a 5th precedence variant this issue didn't originally document.

Confirmed precedence models (verified against current source)

• impact-map-wire.ts (isImpactMapEnabled + shouldComputeImpactMap): env kill-switch AND per-repo review.impact_map toggle — no allowlist role at all. Matches the issue's description exactly. 2 real call sites (processors.ts:7819, :10674).
• review-memory-wire.ts / repo-culture-profile-wire.ts: same shape as impact-map (env + manifest toggle, no allowlist) per their own doc comments, which explicitly say "mirrors isImpactMapEnabled."
• visual-wire.ts (isScreenshotsEnabled + screenshotsAllowed): env kill-switch AND GITTENSORY_REVIEW_REPOS allowlist — no features: override at all, confirmed. But — not documented in the original issue — there is a second, separate manifest-level override already in production: review.visual.enabled (feat(review): config-as-code enable/disable for review.visual capture #4083, resolved via resolveVisualCaptureConfig → resolveReviewVisualConfig), which force-disables capture (enabled === false) on top of the screenshotsAllowed gate. This is functionally a bespoke features.screenshots-shaped toggle that predates and duplicates what this issue wants to build. Unifying screenshots onto resolveConvergedFeature means reconciling with this existing override, not just adding a new one — either fold review.visual.enabled into the new features.screenshots override (a real, user-visible config migration for any repo already using it) or keep both and clearly document which wins. Neither is a config-shape decision I want to make unilaterally without flagging it first.

Recommended implementation order (once picked back up)

1. screenshots — cheapest by call-site count (2: api/routes.ts:1040 for the global-only check, processors.ts:11664 for the per-repo gate), but now the most config-design-sensitive of the four because of the review.visual.enabled overlap above. Do this one last among the four, or explicitly decide the review.visual.enabled reconciliation before starting.
2. impact-map, review-memory, repo-culture-profile — structurally identical precedence today (env + manifest toggle, no allowlist), genuinely the same mechanical migration repeated 3 times: add the key to CONVERGED_FEATURE_KEYS (packages/gittensory-engine/src/focus-manifest.ts:222) + EMPTY_FEATURES_CONFIG (parsing/serialization are already generic over CONVERGED_FEATURE_KEYS, confirmed — no per-key parser code needed), add to FEATURE_GLOBAL_FLAG in feature-activation.ts, swap each call site to resolveConvergedFeature/convergedFeatureActive. Safe to do these 3 first since none has a hidden second override like screenshots does.

Why no code shipped tonight

This is the one item tonight where rushing "properly" and "today" trade off against each other for real — the review.visual.enabled discovery is exactly the kind of thing that would have caused a silent behavior regression (or a confusing dual-config-path) if I'd pushed a same-night PR without surfacing it first. Given this is explicitly called out as the flagship item for the future hosted-version reuse goal, it deserves a dedicated, unhurried pass rather than a rushed first slice under time pressure — recording the concrete plan here so the next session starts from verified findings instead of re-deriving them.