Add lifecycle-aware visual parity capture for runtime state
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 38/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- typescript
- Domain
- testing-qa, tooling
Research direction
Trace the visual-compare capture path and recipe runner, then inspect the existing unit and recipe-runner tests. Define how a recipe declares a stable lifecycle state while preserving duration-based captures. Done means source and candidate captures can wait for and report requested and observed states, with deterministic repeated captures and success/timeout coverage.
Written by the indexing model from the issue text.
Description
Problem
Visual parity currently compares pages after a fixed elapsed duration. Runtime components can be in semantically different states at that moment: source counters may be mid-transition while an imported editable candidate intentionally materializes a deterministic terminal state. Pixel comparison then reports a product defect even though the candidate preserves the declared stable state.
Direction
Add a generic lifecycle-aware capture contract. A recipe step should be able to declare the visual state to compare, with explicit ready/stable hooks or normalized initial/terminal state semantics, instead of relying only on elapsed wall-clock duration. Keep WP Codebox generic and framework-agnostic.
Acceptance
- Visual compare can wait for a declared stable lifecycle state on source and candidate.
- Existing duration-based captures remain supported.
- Timeout/readiness evidence names the requested and observed state.
- Repeated dynamic-component captures are deterministic.
- Unit and recipe-runner tests cover success and timeout behavior.
Evidence
Automattic/blocks-engine#752 documents the Weebly counter case: source capture at 4 seconds observes transient values while deterministic candidate output uses terminal values.
AI assistance
OpenAI gpt-5.6-sol through OpenCode analyzed the parity evidence and drafted this issue. Chris Huber remains responsible for scope and implementation decisions.
- Dominant language
- TypeScript
- Stars
- 17
- Forks
- 4
- Avg merge
- 53m
- Merged PRs (30d)
- 114
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Automattic/wp-codebox
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Automattic/wp-codebox#2467 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Automattic/wp-codebox#2466 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Automattic/wp-codebox#2105 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Automattic/wp-codebox#2061 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Automattic/wp-codebox#1714 · 1 comment ·
All issues in Automattic/wp-codebox
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
ontola/atomic-server#1625 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
melgarafael/DeskcommCRM#1451 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
-
bug via-triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
bot:ai-assisted component:compact-js status:untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
midnightntwrk/midnight-sdk#403 ·