`CadreNode` hardcodes `clusterSize: 3` and drops `allowUnvalidatedSmallCluster`, making db-p2p's own escape hatch unreachable

[risavian]

Affected versions: confirmed in @serfab/cadre-core@0.9.0 (and unchanged from 0.8.1 — both
hardcode the same literal at both call sites), against the resolved runtime peer
@optimystic/db-p2p@0.17.0, whose new membership admission gate consumes exactly the two
options cadre-core fixes and omits.

Companion issues

All four surfaced from the same 4-node cold-start runs (2 Android emulators + 2 Node drones,
2026-07-31). They are independent defects — none is a duplicate of another — but they interact, so
the list is here in full rather than referred to in passing:

#	Where	Status	Relationship to this issue
1	this issue — packages/cadre-core, clusterSize: 3 hardcoded, clusterPolicy not injectable	filing now	The missing seam.
2	gotchoices/Optimystic#10 — the db-p2p membership admission gate has no genesis exemption	filed	Compounds with this issue. That gate is what makes the missing passthrough load-bearing: at cluster genesis it refuses the founding transaction, and the one supported way to opt out (allowUnvalidatedSmallCluster) is the option this issue cannot reach. Still independent in both directions — see "How this relates to the db-p2p gate" below.
3	#1 — a CadreNode's control node and every strand node share one peerId, colliding at a shared circuit-relay-v2 relay	filed, recommendation revised 2026-07-31	Same package, same seam shape (a per-node-type knob a consumer cannot reach), and its revised fix direction is directly relevant to the design question at the end of this issue. Fix landed locally as a yarn patch; fixing it is what let the runs progress far enough to hit the cluster gate.
4	gotchoices/Optimystic#9 — @chainsafe/libp2p-gossipsub@14 paired with libp2p@3, every outbound stream throws	filed	Unrelated mechanism, same runs. Listed for completeness: its unbounded error stream dominated the drone logs while the cluster blockers were being diagnosed.

Summary

CadreNode builds the createLibp2pNode options for both its node types with a hardcoded
cluster policy:

clusterSize: 3,
clusterPolicy: { allowDownsize: true, sizeTolerance: 0.5 },

Two problems, both of which became load-bearing when @optimystic/db-p2p@0.17.0 introduced its
membership admission gate:

1. clusterSize: 3 is a literal with no CadreNodeConfig override. NetworkConfig exposes no
   cluster-size field, so a consumer running a deliberately small cohort (or a large one) cannot
   change it.
2. clusterPolicy is constructed inline and omits allowUnvalidatedSmallCluster. db-p2p
   defaults that option to false (fail closed). Because cadre-core passes a clusterPolicy object
   that does not include the key, and offers no way to inject one, the escape hatch db-p2p provides
   for precisely this situation cannot be reached through cadre-core at all.

The consequence is that a cadre cold-starting a cohort deadlocks: db-p2p's gate refuses the founding
transaction as a possible self-shrink (membership-not-admitted:low-confidence-downsize), and the
one supported way to opt out of that refusal is not plumbed.

Reproduction

Both call sites, in the installed 0.9.0 dist:

// dist/cadre-node.js:503-504 — CONTROL node
clusterSize: 3,
clusterPolicy: { allowDownsize: true, sizeTolerance: 0.5 },

// dist/strand-instance-manager.js:170-173 — every STRAND node
clusterSize: 3,
clusterPolicy: {
    allowDownsize: true,
    sizeTolerance: 0.5
},

Neither reads anything from CadreNodeConfig. Confirming the absence of an override:

$ grep -n "clusterSize\|clusterPolicy" node_modules/@serfab/cadre-core/dist/types.d.ts
$    # (no output — NetworkConfig / CadreNodeConfig expose neither)

Downstream, db-p2p resolves the missing key to the fail-closed default
(db-p2p/dist/src/libp2p-node-base.js:418):

allowUnvalidatedSmallCluster: options.clusterPolicy?.allowUnvalidatedSmallCluster ?? false,

…and its member-side gate then refuses every below-3-peer declared set while FRET confidence is
still 0 (db-p2p/dist/src/cluster/cluster-repo.js:691-708).

Observed end to end on a 4-node topology (2 Android emulators + 2 Node drones, cold-started
together), on the first schema DDL:

Transaction rejected by validators (2/2 rejected):
  12D3KooWR3zSSnvr…: membership-not-admitted:low-confidence-downsize;
  12D3KooWMVS8M6dQ…: membership-not-admitted:low-confidence-downsize

Deterministic across two independent runs with freshly wiped state.

The runnable test at the bottom of this issue isolates the seam without any of that: it drives the
real CadreNode.createControlNode() against a stubbed createLibp2pNode and shows a consumer's
clusterSize: 2 and clusterPolicy: { allowUnvalidatedSmallCluster: true } being dropped —
db-p2p receives clusterSize: 3 and a policy object with no such key.

Expected: a consumer can tell cadre-core the shape of its cohort — at minimum, that it knowingly
runs below db-p2p's safe floor — the same way db-p2p lets its own direct callers do.

Actual: cluster sizing is fixed at 3, allowUnvalidatedSmallCluster is unreachable, and a
small-cohort deployment cannot start.

Root cause

this.config is stored verbatim (cadre-node.js:171), but the cluster options are not read from it
— they are literals written into the option object at each createLibp2pNode call site
(cadre-node.js:503-504, strand-instance-manager.js:170-173). Contrast the adjacent lines, which
do forward consumer config:

...(config.privateKey && { privateKey: config.privateKey }),
...(config.network?.transports && { transports: config.network.transports }),
...(config.network?.listenAddrs && { listenAddrs: config.network.listenAddrs }),
...(config.network?.connectionGater && { connectionGater: config.network.connectionGater })

The cluster options simply were not given the same treatment.

How this relates to the db-p2p gate (companion issue 2)

They are independent defects that compound, and both are worth fixing:

• Even if cadre-core forwarded allowUnvalidatedSmallCluster, db-p2p would still deadlock at genesis
  for every consumer that does not set it — including anyone using db-p2p directly with a
  clusterSize and default policy. That is The membership admission gate has no genesis exemption, so a cold-starting cluster's founding transaction can never be admitted Optimystic#10.
• Even if db-p2p exempted genesis, cadre-core would still hardcode clusterSize: 3 with no way for a
  consumer to size their cohort or reach any db-p2p cluster-policy knob. That is this issue.

Fixing Optimystic#10 alone unblocks the deployment. Fixing this issue alone would also unblock it (by
letting the consumer set allowUnvalidatedSmallCluster: true), but at the cost of turning off a real
safety gate — so Optimystic#10 is the one to push on, and this is the durable configurability fix.

Fix

Additive and symmetric with the existing forwarding style — add optional fields to NetworkConfig
(or CadreNodeConfig) and prefer them when present, so callers that set nothing see zero behavior
change:

  // cadre-node.ts (createControlNode) and strand-instance-manager.ts (buildStrandRuntime)
- clusterSize: 3,
- clusterPolicy: { allowDownsize: true, sizeTolerance: 0.5 },
+ clusterSize: config.network?.clusterSize ?? 3,
+ clusterPolicy: {
+     allowDownsize: true,
+     sizeTolerance: 0.5,
+     ...config.network?.clusterPolicy,
+ },

  // types.ts — NetworkConfig
+ /** Full cluster size for consensus sizing. Defaults to 3. */
+ clusterSize?: number;
+ /** Cluster policy overrides forwarded to the underlying db-p2p node
+  *  (e.g. `allowUnvalidatedSmallCluster` for knowingly-small cohorts). */
+ clusterPolicy?: {
+     allowDownsize?: boolean;
+     sizeTolerance?: number;
+     allowUnvalidatedSmallCluster?: boolean;
+     superMajorityThreshold?: number;
+ };

Spreading the consumer's clusterPolicy last preserves cadre-core's defaults for keys the consumer
does not set, while letting allowUnvalidatedSmallCluster (and any future db-p2p policy key) through.

One design question: shared or per-node-type?

Whether the control node and strand nodes should share one setting or take independent ones is worth
a moment's thought, and sereus#1 (companion issue 3) is the relevant precedent — in its revised
form especially. That issue's recommendation was updated on 2026-07-31: its primary fix is now
distinct transport peerIds per node (decoupling the transport peerId from the cadre's owner
key), with the per-strand strandNetwork override retained as the companion approach for callers
that deliberately reuse one privateKey/peerId. Both halves of that revision point the same way as
this issue: CadreNodeConfig is growing knobs that a cadre's control node and its strand nodes need
to set differently.

Forwarding a single value from network is still the minimal step here and can be split later; if
sereus#1's per-node-type config direction lands first, these two options are natural candidates to
travel with it.

Severity

High. In combination with db-p2p 0.17's admission gate it is a hard blocker for cold-starting any
cohort smaller than 3 confident peers — the deployment cannot create a schema, so it never becomes
usable. Even once the db-p2p genesis defect is fixed, the missing passthrough remains a real
limitation: consumers cannot size their cohort or opt into small-cluster operation.

Regression test

Self-contained; no test-framework dependency (built-in node:test + node:assert) and no sockets —
createLibp2pNode is mocked so it records the options cadre-core hands it, and the test then drives
the real CadreNode.createControlNode(), the same builder start() calls. Drop it in as
packages/cadre-core/test/cadre-cluster-config-passthrough.test.mjs and run:

node --test --experimental-test-module-mocks \
  packages/cadre-core/test/cadre-cluster-config-passthrough.test.mjs

Against 0.9.0 both assertions fail — the consumer's values never reach db-p2p:

✖ a consumer-supplied clusterSize reaches the underlying db-p2p node
✖ a consumer-supplied clusterPolicy reaches the underlying db-p2p node
ℹ tests 2
ℹ pass 0
ℹ fail 2

✖ failing tests:

✖ a consumer-supplied clusterSize reaches the underlying db-p2p node
  AssertionError [ERR_ASSERTION]: the consumer asked for a 2-peer cohort but db-p2p received
  clusterSize: 3. It is a literal at cadre-node.ts (createControlNode) and strand-instance-manager.ts
  (buildStrandRuntime), and NetworkConfig exposes no field for it, so cohort size cannot be
  configured at all.
      actual: 3, expected: 2

✖ a consumer-supplied clusterPolicy reaches the underlying db-p2p node
  AssertionError [ERR_ASSERTION]: the consumer opted into small-cluster operation but db-p2p received
  clusterPolicy {"allowDownsize":true,"sizeTolerance":0.5} — the key is absent, so db-p2p resolves it
  to its fail-closed default (`options.clusterPolicy?.allowUnvalidatedSmallCluster ?? false`).
  cadre-core builds clusterPolicy inline and offers no way to inject one, so db-p2p's own escape
  hatch for knowingly-small cohorts is unreachable through cadre-core.
      actual: undefined, expected: true

Both pass once the two options are forwarded from config. The third assertion (that cadre-core's own
allowDownsize default survives a partial consumer override) guards the spread order in the fix
above. The mock re-exports the real db-p2p namespace and overrides only createLibp2pNode, so other
consumers in the graph keep resolving normally.

packages/cadre-core/test/cadre-cluster-config-passthrough.test.mjs

/**
 * cadre-cluster-config-passthrough.test.mjs
 *
 * Regression test for: `CadreNode` writes `clusterSize: 3` and an inline `clusterPolicy` as literals
 * into the `createLibp2pNode` options at BOTH call sites, and `CadreNodeConfig`/`NetworkConfig`
 * expose no field for either — so a consumer can neither size its cohort nor reach db-p2p's
 * `allowUnvalidatedSmallCluster` escape hatch, which db-p2p defaults to `false` (fail closed).
 *
 * The test mocks `@optimystic/db-p2p` so `createLibp2pNode` records the options object cadre-core
 * hands it, then drives the REAL `CadreNode.createControlNode()` — cadre-core's own control-node
 * builder, the one `start()` calls. No sockets: the factory is a stub.
 *
 * The consumer below asks for a 2-peer cohort and knowingly opts into small-cluster operation. Both
 * assertions check that what the consumer asked for is what db-p2p receives.
 *
 * These assertions are written to FAIL while the defect is present and PASS once the two options are
 * forwarded from config.
 *
 * Run:  node --test --experimental-test-module-mocks cadre-cluster-config-passthrough.test.mjs
 * (No test-framework dependency — uses the built-in `node:test` and `node:assert`.)
 */

import test, { mock } from 'node:test';
import assert from 'node:assert/strict';
import { generateKeyPair } from '@libp2p/crypto/keys';

/** Options handed to createLibp2pNode by whichever cadre-core call site ran last. */
let capturedOptions;

// The mock replaces the module for EVERY importer in the graph, so re-export the real namespace and
// override only `createLibp2pNode` — other db-p2p consumers (e.g. quereus-plugin-optimystic) need
// their own imports to keep resolving.
const realDbP2p = await import('@optimystic/db-p2p');

// Must be registered BEFORE cadre-core is imported, so its `createLibp2pNode` specifier resolves here.
mock.module('@optimystic/db-p2p', {
	exports: {
		...realDbP2p,
		createLibp2pNode: async (options) => {
			capturedOptions = options;
			// Minimal stand-in for a libp2p node — cadre-core only needs it to look like one here.
			return {
				peerId: { toString: () => 'stub-peer' },
				services: {},
				addEventListener () {},
				getMultiaddrs: () => [],
				start: async () => {},
				stop: async () => {},
			};
		},
	},
});

const { CadreNode } = await import('@serfab/cadre-core');

/** A consumer that deliberately runs a 2-peer cohort and says so. */
const CONSUMER_CLUSTER_SIZE = 2;

async function buildControlNodeOptions () {
	capturedOptions = undefined;
	const node = new CadreNode({
		controlNetwork: { partyId: 'partyX', bootstrapNodes: [] },
		privateKey: await generateKeyPair('Ed25519'),
		profile: 'edge',
		network: {
			// What a consumer would set if the seam existed. Today these are simply ignored.
			clusterSize: CONSUMER_CLUSTER_SIZE,
			clusterPolicy: { allowUnvalidatedSmallCluster: true },
		},
	});
	await node.resolveIdentityKey();
	await node.createControlNode();
	assert.ok(capturedOptions !== undefined, 'createLibp2pNode was not called — test harness problem');
	return capturedOptions;
}

test('a consumer-supplied clusterSize reaches the underlying db-p2p node', async () => {
	const options = await buildControlNodeOptions();

	assert.equal(
		options.clusterSize,
		CONSUMER_CLUSTER_SIZE,
		`the consumer asked for a ${CONSUMER_CLUSTER_SIZE}-peer cohort but db-p2p received ` +
		`clusterSize: ${options.clusterSize}. It is a literal at cadre-node.ts (createControlNode) ` +
		'and strand-instance-manager.ts (buildStrandRuntime), and NetworkConfig exposes no field for ' +
		'it, so cohort size cannot be configured at all.',
	);
});

test('a consumer-supplied clusterPolicy reaches the underlying db-p2p node', async () => {
	const options = await buildControlNodeOptions();

	assert.equal(
		options.clusterPolicy?.allowUnvalidatedSmallCluster,
		true,
		'the consumer opted into small-cluster operation but db-p2p received clusterPolicy ' +
		`${JSON.stringify(options.clusterPolicy)} — the key is absent, so db-p2p resolves it to its ` +
		'fail-closed default (`options.clusterPolicy?.allowUnvalidatedSmallCluster ?? false`). ' +
		'cadre-core builds clusterPolicy inline and offers no way to inject one, so db-p2p\'s own ' +
		'escape hatch for knowingly-small cohorts is unreachable through cadre-core.',
	);

	// The cadre-core defaults must survive a partial consumer override — spread the consumer's
	// policy over them rather than replacing the object.
	assert.equal(
		options.clusterPolicy?.allowDownsize,
		true,
		'cadre-core\'s own clusterPolicy defaults should be preserved for keys the consumer does not set',
	);
});

[n8allan]

Fixed, with one caveat worth stating plainly because it changes what "fixed" means for the second half of the title.

Same timing as #1: v0.9.0 was cut 2026-07-27, the fix landed 2026-07-28 in 823c66b (ticket(implement): bug-cluster-size-exceeds-cadre-size), and this was filed 07-31 against 0.9.0. It first shipped in @serfab/cadre-core@0.10.0 (2026-08-08).

The hardcode is gone. There is no clusterSize: 3 literal anywhere in packages/cadre-core/src or packages/quereus-plugin-sereus/src. A strand node is built with clusterSize: resolveStrandClusterSize(config.clusterSize) — consumer-injectable, validated, defaulting to DEFAULT_STRAND_CLUSTER_SIZE. The policy is no longer an inline object literal either: packages/quereus-plugin-sereus/src/cluster-size.ts now owns CONTROL_CLUSTER_POLICY and STRAND_CLUSTER_POLICY as separate frozen constants, and the strand call site carries a comment saying the shape match between them is a coincidence rather than a shared rule.

The caveat: allowUnvalidatedSmallCluster is not reachable because it no longer exists. It is absent from @optimystic/db-p2p entirely. So "makes db-p2p's own escape hatch unreachable" is now moot in the literal sense — the hatch was removed upstream, not merely left unplumbed, and adding a passthrough for it would plumb nothing.

What does that job now is assumedClusterSize, which both policies above declare (MIN_CLUSTER_SIZE, i.e. 2). It relaxes optimystic's read-repair corroboration floor for a genuinely small cohort — corroboratorCapacity takes the MAX of the cohort actually present and the declared number, so the relaxed branch is only reachable by a cohort that really is that small. That declaration is what fixed the small-cohort case for the control network in 42cd12c, and the strand path was given the same treatment later.

If your original need was "a 2-to-3 node cluster must be able to reach genesis and repair", that is addressed by a different mechanism than the one this issue asked for. If you were relying on allowUnvalidatedSmallCluster specifically for something assumedClusterSize does not cover, that would be worth a fresh issue against the current versions, since the option it names is gone from the dependency.

Leaving this open for you to judge and close.

[risavian]

Confirming the first half and correcting the record on the second. Leaving this open for your call, since the correction changes what (if anything) is left to do.

The hardcode half is fixed — verified at @serfab/cadre-core@0.11.0. No clusterSize: 3 literal survives; strand-instance-manager.js:244 reads clusterSize: resolveStrandClusterSize(config.clusterSize), and CONTROL_CLUSTER_POLICY / STRAND_CLUSTER_POLICY are separate frozen constants in quereus-plugin-sereus/src/cluster-size.ts. Agreed on all of that.

But allowUnvalidatedSmallCluster has not been removed from @optimystic/db-p2p. It is present and documented in the version cadre-core 0.11.0 actually resolves, 0.24.2:

• declared on clusterPolicy at src/cluster/cluster-policy.ts:94
• resolved at src/cluster/cluster-policy.ts:188 (options.clusterPolicy?.allowUnvalidatedSmallCluster ?? false)
• consumed as a live opt-in branch in admitMembership at src/cluster/cluster-repo.ts:988

It is still there in 0.25.1 as well, unchanged. So "the hatch was removed upstream, not merely left unplumbed" doesn't hold, and the issue title's second clause is still literally true at 0.11.0: clusterPolicy is a hard-coded constant at both call sites (cadre-node.js:903, strand-instance-manager.js:247) with no consumer override — unlike clusterSize, which you did make injectable.

That said, your conclusion still looks right to us, for a different reason than the one given. allowUnvalidatedSmallCluster only skips the membership admission size/consistency gates. It never touches the read-repair corroboration floor, which is the thing that actually bites us. So plumbing it would not fix anything we have hit, and we are not asking for it.

What we would ask for instead is that the record be accurate about why, since the current reasoning would mislead the next person who greps for that option and finds it alive in their node_modules. Either:

1. re-close with the accurate reason — the option exists but is deliberately not plumbed, because assumedClusterSize is the mechanism that addresses the small-cohort case and this one does not; or
2. keep it open as a small plumbing request, if you would rather clusterPolicy be consumer-injectable on principle.

Either is fine by us. For context on why we care about the distinction: our own small-cohort failure was root-caused to the corroboration floor rather than the admission gate, filed as gotchoices/Optimystic#15, and closed there as documented-by-design — 0.25.1 carries the same arithmetic plus a cluster-fetch:repair-deadlock / reason=sole-holder diagnostic. So assumedClusterSize genuinely is the only one of the two levers in play, which supports your call.

One unrelated note while you have this open: cadre-core 0.11.0 and quereus-plugin-sereus 0.11.0 both pin @optimystic/* ^0.24.0, which excludes the 0.25.x line published on 2026-09-01. Consumers who want 0.25.x currently have to force it with a resolution override and run cadre-core against a range it was not tested at. A 0.12.0 widening that pin would be welcome whenever it fits your schedule.

[n8allan]

This issue got more important yesterday, and the reason comes from the Optimystic side, so it is worth saying here rather than leaving you to infer it.

A design question was settled that this issue now blocks

We had an open decision on whether a two-machine cohort is a supported production topology or a development convenience. Several safety rules were written on the second assumption, and one carried an explicit "revisit if this ever becomes a real topology" note.

It is settled: any size is supported, and small sizes are ordinary. A cadre starts as one machine — typically a phone — and the ordinary next step is a second added as a backup: a pod in the cloud, or a desktop or Linux box for an advanced user. Alternatively the user goes straight from one phone to pairing with another member's cadre, which may itself be a single phone (relayed, since two phones cannot dial each other). Cadres of any size join cadres of any size.

That makes this issue's two findings load-bearing rather than tidy-up:

• clusterSize: 3 as a literal with no CadreNodeConfig override means the supported sizes cannot be expressed through cadre-core at all.
• The inline clusterPolicy omitting allowUnvalidatedSmallCluster means the escape hatch db-p2p provides for exactly this situation cannot be reached through cadre-core, as you wrote in July.

The concrete way it bites right now

We have just documented that a two-machine deployment must declare clusterPolicy.assumedClusterSize: 2 (or an honest clusterSize: 2) before its members can repair each other — undeclared, the corroboration floor defaults to the replication factor and repair can never succeed, which is measurable as a permanent stream of cluster-fetch:no-quorum.

That advice is currently inert for anything built on cadre-core, because there is no seam to pass it through. We would be telling users to set something their host cannot forward. That is a documentation bug on our side created by a code gap on yours, and neither half is fixable alone.

What your issue changed on our side

Your framing shifted our own conclusion, so credit where it is due. A hardcoded 3 is not a careless literal — it is what a downstream author reasonably writes when the upstream docs imply three is the real minimum. Ours did imply that. We have reframed them (architecture.md, optimystic.md, transactions.md, internals.md, db-p2p/docs/cluster.md): one and two are supported sizes, and the declared-size requirement is a rough edge on an ordinary path rather than evidence of a misconfigured deployment.

It also changed what we think the right fix is. Our planning ticket now records the argument that this should end up as a default, not a setting: a machine that joins because a user tapped "add a backup" has no operator to configure it, so a design that depends on someone declaring a size is solving the wrong problem. What that means for CadreNodeConfig is yours to decide — a passthrough is the minimum, but it may not be the whole answer.

Status, honestly

Nothing has shipped on our side that closes this. What exists is a decision, updated docs, and a plan ticket that owns the trust-rule work for cohort sizes one and two. The escape hatch you cannot reach still exists and still defaults to fail-closed; we have not changed that default, and we would want to hear from you before we did.

[n8allan]

Closing this, taking the first of the two options you offered — re-close with the accurate reason. Your correction stands and mine was wrong, so the record should say so plainly before the issue goes quiet.

allowUnvalidatedSmallCluster was never removed from @optimystic/db-p2p. You checked 0.24.2 and 0.25.1 and found it live; it is still there in 0.29.0, published today — declared on clusterPolicy (cluster/cluster-policy.ts:110), resolved at :435, and consumed as a live opt-in branch in admitMembership (cluster/cluster-repo.ts:1153). My earlier "the hatch was removed upstream, not merely left unplumbed" was simply false, and anyone who greps their node_modules will find it alive exactly as you said.

The accurate reason it stays unplumbed is the one you supplied: it gates membership admission only. It never touches the read-repair corroboration floor, which is the thing that actually bit both of us. Plumbing it would not have fixed anything either of us hit.

And the lever that does matter now has its own seam, which is what changed since my last comment. 0.29.0 adds clusterPolicy.repairCorroborationClusterSize, declaring the repair corroboration floor's yardstick alone. Until now the only way to raise it was assumedClusterSize, which also raises the membership admission gate's low-confidence write floor — so a small deployment that wanted repair tightened had to accept a floor that can refuse legitimate writes, and cadre-core pinned assumedClusterSize: 2 at every group size for exactly that reason, and therefore got no repair tightening at all. That was the gap behind my "we would be telling users to set something their host cannot forward". It is a real setting now.

Two honest qualifications on it, since over-declaring is worse than declaring nothing: the number is the size of the cohort that actually serves the network, which is not the same as the number of machines enrolled; and it is read once when a node is built, so a changed value applies on rebuild rather than live.

The cadre-core side that derives it from membership has landed here but is not published yet — it ships in the next cadre-core release, which also widens the @optimystic/* pin you asked about (0.12.0 declares ^0.27.0, which excludes both 0.28.x and 0.29.x).

Nothing above is a reason to keep this issue open: the hardcode is fixed and you verified it, and the option in the title is deliberately not plumbed for a reason you agree with. If the corroboration seam turns out not to cover your case, that is a fresh issue against 0.29.0 rather than a reopen of this one — but reopen it if you think I have closed it on a wrong premise again.