QA run · 17.1.0-touched api surface · 9/12 · 19f98fa1 · 2026-08-20

[os-elon]

Seventh run of the 17.1.0 post-release sweep. Target set: the api-surface slice of the computed focus list from #10257 (17.1.0-touched × unadjudicated × P0/P1 × not standing-blocked) — 12 items, 9 adjudicated here.

Companions: #10224 · #10225 · #10233 · #10245 · #10248 · #10257. Anchor: #10236.
Environment as before: framework 19f98fa1, objectui pin 9a3daf8d37ad, showcase on 3456, file DB. Execution mode: SEQUENTIAL, declared.

Verdicts

item	rev	verdict	basis
access-security.scope-depth-asymmetry	2	pass	pin green, no manual remainder declared
ai.mcp-http-surface	2	pass	pin green
integration-system.connector-declarative-boot	1	pass	pin green
platform-core.metadata-registry-serving	3	pass	pin green
search.cross-field-object-search	2	pass	pin green
search.field-scoped-narrowing	2	pass	pin green
records-forms.validation-rule-type-matrix	1	pass 4/4, variants 6/6	hand-driven, below
attachments-storage.read-inherits-parent-rls	3	partial	pin green but its automated.ref declares a NOT-REACHED arm
attachments-storage.attach-requires-parent-edit	2	partial	pin green; clause 3 deliberately unpinned against a known product gap (#9719)

The six pin-based passes follow RUNNER rule 6 (do not re-prove what automation pins). Each was checked first for a STILL MANUAL / NOT PINNED declaration in its automated.ref; the six carry none, so pin-green is the item verdict. The two attachments items do carry one, which is why they stay partial rather than riding the same green.

No fail in this run. Seven runs, zero product defects.

records-forms.validation-rule-type-matrix — the full 6-variant matrix

Driven against the seeded per-type rules on showcase_account and showcase_project.

variant	violating write	field code	happy-path twin
format (regex)	tax_id: "not-an-ein"	400 VALIDATION_FAILED · field tax_id · invalid_format	12-3456789 → 201
format (named email)	billing_email: "notanemail"	field billing_email · invalid_format	—
json_schema	support_config: {tier:"bogus_tier"}	field support_config · json_schema_violation	{tier:"premium",seats:5} → 201
conditional	status:"churned" with no churn_reason	400, "A churn reason is required when an account is marked churned."	with churn_reason → 201
state_machine	churned → prospect	invalid_transition, "Invalid account lifecycle transition."	prospect → active → 200
cross_field	end_date < start_date	rule_violation · field start_date	ordered dates → 201
script	spent 1500 vs budget 1000 (>120%)	rule_violation, "Spend exceeds 120% of budget"	spent 1100 (110%) → 201

• [0] pass — every per-type field code matches the ledgered spelling
• [1] pass — errors target the declared field, and cross_field targets fields[0] (start_date), exactly as the spec's own comment prescribes
• [2] pass — showcase_account went 14 → 18 and showcase_project 5 → 7, i.e. only the happy-path twins landed; no rejected write persisted
• [3] pass — every happy-path twin answered 2xx

Checklist finding: one variant contradicts its own fixture

The matrix lists:

state_machine — create with non-initial status → invalid_initial_state

But the seeded rule declares events: ['update'] (account.object.ts, with the comment "Transitions are validated on update; insert sets the initial state"). Measured: creating an account directly with status: 'churned' answers 201 — no invalid_initial_state, because insert is out of the rule's declared event set. The variant describes behaviour this fixture cannot produce. Either the variant should drop the create arm, or a second rule with events: ['insert'] is needed to demonstrate it.

Parked-on: #10236 · records-forms.validation-rule-type-matrix — the state_machine variant's create arm contradicts the seeded rule's events:['update']

Two self-inflicted false signals, caught before they became verdicts

Recorded because the run record is where they belong, not the verdict table:

1. churned → active first read as a FAIL (400 on a legal transition). Self-check per RUNNER rule 2 showed the refusal message carried two rule messages; isolating them proved the 400 came from churn_reason_consistency (the record still held a churn_reason), not from the state machine. With churn_reason: null in the same PATCH the transition answers 200, and the prospect → active control answers 200 with no churn field involved.
2. The first showcase_project pass produced three FAILs all reading Account is required — a required relation my payload omitted. The two "violation refused" lines were false positives (refused for the missing field, not by the rule under test). Re-run with a real account id produced the real per-rule refusals above.

Neither reached the verdict table. The remaining three api items (ai.agent-tool-skill-metadata-roundtrip, ai.mcp-run-action-exposure-gate, integration-system.connector-degraded-recovery) were not attempted: the first needs authoring into a writable package, the second an MCP client, the third a deliberately broken upstream config in the shared checkout.