Problem
Fixture lifecycle resume currently uses getmypid() as its request identity in Static_Site_Importer_Theme_Generator::runtime_request_id(). WP Codebox can execute separate wordpress.wp-cli recipe steps in the same persistent PHP worker, so the prepare receipt and later validation request have the same PID even though they are distinct commands.
As a result, fixture 87 now passes Jetpack 16 dependency preparation and provider readiness, but validate-artifact returns static_site_importer_fresh_runtime_required. No page is materialized, and later editor steps fail because show_on_front / page_on_front are unset.
Reproduction
From a clean Static Site Importer issue worktree and current Blocks Engine primary:
node tools/run-fixture-matrix.mjs \
--local \
--static-site-importer /path/to/static-site-importer \
--blocks-engine /path/to/blocks-engine \
--target-fixture 87-travel-tours \
--run-id ssi-848-fixture87-proof3 \
--batch-size 1 \
--concurrency 1 \
--no-visual-parity
Observed Homeboy run: 06b327d8-269a-4de4-9280-0da490e5e07b.
Evidence:
- Extra plugin activation succeeds for Jetpack and SSI.
- Dependency preparation succeeds.
- Provider readiness reports
ready: true, no missing classes, and no missing block types across all 17 required Jetpack Forms blocks.
- The next
validate-artifact command returns static_site_importer_fresh_runtime_required because the persisted PID equals the persistent worker PID.
- Editor steps then report no static front page because materialization did not run.
Direction
Represent lifecycle invocation identity with a value that changes across distinct WP CLI recipe commands even when the PHP worker process is reused. Preserve rejection of an actual same-invocation resume. Add deterministic coverage for both persistent-worker sequential commands and genuine same-invocation calls, then rerun fixture 87 through rendering and submission evidence.
AI assistance
OpenAI GPT-5.6 Sol via OpenCode and Homeboy traced the fixture run, inspected the persisted recipe/output, and identified the PID collision. Chris Huber directed the investigation and remains responsible for the issue.
Problem
Fixture lifecycle resume currently uses
getmypid()as its request identity inStatic_Site_Importer_Theme_Generator::runtime_request_id(). WP Codebox can execute separatewordpress.wp-clirecipe steps in the same persistent PHP worker, so the prepare receipt and later validation request have the same PID even though they are distinct commands.As a result, fixture 87 now passes Jetpack 16 dependency preparation and provider readiness, but
validate-artifactreturnsstatic_site_importer_fresh_runtime_required. No page is materialized, and later editor steps fail becauseshow_on_front/page_on_frontare unset.Reproduction
From a clean Static Site Importer issue worktree and current Blocks Engine primary:
Observed Homeboy run:
06b327d8-269a-4de4-9280-0da490e5e07b.Evidence:
ready: true, no missing classes, and no missing block types across all 17 required Jetpack Forms blocks.validate-artifactcommand returnsstatic_site_importer_fresh_runtime_requiredbecause the persisted PID equals the persistent worker PID.Direction
Represent lifecycle invocation identity with a value that changes across distinct WP CLI recipe commands even when the PHP worker process is reused. Preserve rejection of an actual same-invocation resume. Add deterministic coverage for both persistent-worker sequential commands and genuine same-invocation calls, then rerun fixture 87 through rendering and submission evidence.
AI assistance
OpenAI GPT-5.6 Sol via OpenCode and Homeboy traced the fixture run, inspected the persisted recipe/output, and identified the PID collision. Chris Huber directed the investigation and remains responsible for the issue.