morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 07:47:29 +00:00

[PR #7149] [CLOSED] feat(cli): validate a browser scenario without launching a browser #7676

New issue

Closed

opened 2026-11-03 13:39:34 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-03 13:39:34 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/7149
Author: @z2Ace0107
Created: 10/25/2026
Status: ❌ Closed

Base: main ← Head: feat/5488-browser-scenario-validation

📝 Commits (1)

463c8bd feat(cli): validate a browser scenario without launching a browser

📊 Changes

4 files changed (+321 additions, -1 deletions)

View changed files

📝 docs/browser-scenario-contract.md (+24 -0)
📝 src/cliBrowserScenarioCommands.ts (+64 -1)
📝 src/cliCommandNames.ts (+1 -0)
➕ tests/boundary/cli/browserScenarioValidation.test.ts (+232 -0)

📄 Description

feat(cli): validate a browser scenario without launching a browser

Summary

Fixes #5488.

validate-browser-scenario INPUT_JSON
  parseCliJsonInput                      # inline JSON, file path, or '-'
  resolveCliJsonPaths                    # same operator-relative resolution as capture
  browserScenarioSchema.safeParse        # the exact schema capture admits
    ├── reject → projected input error with field paths
    └── accept → { valid: true, actions, secrets }   # no provider, no browser

Problem and expected behavior

A browser scenario carries actions, selectors, storage seeds and secret
references. Today the only way to learn that a scenario is invalid is to run
capture-browser-scenario, which has already resolved a provider by the time
the schema is checked. Issue #5488 asks for a validation-only workflow that
reuses the same canonical schema and semantic validation but stops before
browser discovery, launch, attachment, or navigation.

Change and scope

validate-browser-scenario shares the capture command's input path exactly: the
same parseCliJsonInput, the same resolveCliJsonPaths for
browser.executable_path, and the same browserScenarioSchema refinement.
Duplicate or reserved step IDs, duplicate secret identities and
environment-variable names, undeclared secret references, request-step
violations, and unknown fields are therefore rejected here with the same field
paths capture reports, so a correction made here is the correction capture
needs. Failures reuse analysisInputErrorFromIssues, so the reported operation
stays capture_browser_scenario.

Deliberately not included: no new MCP operation (CLI-only command); no read of
secret environment variables, so a scenario whose declared variables are unset
still validates, because the missing-value failure belongs to capture; no check
that the browser executable or CDP target exists on the host. The scenario
contract itself (src/domain/browserScenario.ts) is unchanged.

Contract and boundary impact

Semantic owner and earliest changed stage: the CLI adapter boundary
(src/cliBrowserScenarioCommands.ts); the scenario contract owner is untouched.
Contribution scope fit and linked maintainer decision: not applicable — this
stays inside the existing CLI adapter and the existing scenario contract, and
involves no target execution, injection, mutation, or protection recovery.
CLI and MCP/tool-catalog contract: adds validate-browser-scenario to
CLI_COMMANDS. No MCP tool, no catalog operation, no input/output schema change.
Provider, bridge, target-format, or platform compatibility: none. No provider
is constructed and Playwright is not imported.
Evidence, artifact, provenance, or reconstruction contract: none; no Evidence
is produced.
Generated metadata (docs/public/product-catalog.json): generated and
validated by CI; not committed here.

Expected effects (checked): documentation or usability only; no target
interaction.

Evidence and regression coverage

Tests added: tests/boundary/cli/browserScenarioValidation.test.ts, 7 cases —
valid scenario, declared secrets counted without resolution, duplicate step
identity, reserved initial step identity, undeclared secret reference,
unknown field, unreadable input file.
Base reproduction: before this change there was no validation-only entry
point; the schema was only reached after provider resolution.
Mutation evidence (each new case against one deliberate production change):
constructing a provider — killed; counting only resolved secrets — killed;
dropping the step-ID uniqueness assertion — killed; dropping the
undeclared-secret check — killed; relaxing the strict request object — killed;
disabling the reserved-step check — killed. 6/6 killed.
User-visible output: {"valid":true,"actions":1,"secrets":0} on success; the
projected input error with field paths on failure.
Remaining proof gaps: the acceptance lane and the dist/-dependent
catalog/identity suites were not run for this change; --project cli-boundary
has 110 pre-existing failing files on this Windows host, verified identical on
unmodified main, and this change adds one passing file and no new failure.

Validation performed

vitest run tests/boundary/cli/browserScenarioValidation.test.ts — 7 passed
mutation check (6 mutations) — 6/6 killed
npm run verify:test-discovery — 2484 files discovered exactly once
npm run verify:module-boundaries — 3059 source files checked
oxfmt --check . — all matched files correctly formatted
oxlint on the four changed files — no new findings
vitest run --project cli-boundary — 110 failed / 34 passed / 35 skipped,
against 110 failed / 33 passed / 35 skipped on unmodified main

Compatibility, safety, and release

Breaking changes or migration steps: none; the command is additive.
Real Hopper/Ghidra, browser, or OS coverage: none required — no browser is
launched and no provider is constructed.
Package or release metadata impact: CLI_COMMANDS grows by one entry; the
generated product catalog picks it up in CI.
Security, privacy, process, or containment review: no secret values are read
or printed; validation reports counts and field paths only.

Author readiness

Human owner: @z2Ace0107

I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
I declare this PR ready for initial maintainer review.

Before merge

This PR addresses a concrete problem or an agreed enhancement.
Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked, or the reason for not linking one is stated above.
Tests cover changed observable behavior and meaningful failure paths.
Owning docs, contracts, and generated metadata are updated where needed.
User-visible CLI/MCP changes include representative output.
I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/7149 **Author:** [@z2Ace0107](https://github.com/z2Ace0107) **Created:** 10/25/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `feat/5488-browser-scenario-validation` --- ### 📝 Commits (1) - [`463c8bd`](https://github.com/morluto/rea/commit/463c8bd73b7e38f47001fe97702b73ab5a4596c3) feat(cli): validate a browser scenario without launching a browser ### 📊 Changes **4 files changed** (+321 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `docs/browser-scenario-contract.md` (+24 -0) 📝 `src/cliBrowserScenarioCommands.ts` (+64 -1) 📝 `src/cliCommandNames.ts` (+1 -0) ➕ `tests/boundary/cli/browserScenarioValidation.test.ts` (+232 -0) </details> ### 📄 Description feat(cli): validate a browser scenario without launching a browser ## Summary Fixes #5488. ```text validate-browser-scenario INPUT_JSON parseCliJsonInput # inline JSON, file path, or '-' resolveCliJsonPaths # same operator-relative resolution as capture browserScenarioSchema.safeParse # the exact schema capture admits ├── reject → projected input error with field paths └── accept → { valid: true, actions, secrets } # no provider, no browser ``` ## Problem and expected behavior A browser scenario carries actions, selectors, storage seeds and secret references. Today the only way to learn that a scenario is invalid is to run `capture-browser-scenario`, which has already resolved a provider by the time the schema is checked. Issue #5488 asks for a validation-only workflow that reuses the same canonical schema and semantic validation but stops before browser discovery, launch, attachment, or navigation. ## Change and scope `validate-browser-scenario` shares the capture command's input path exactly: the same `parseCliJsonInput`, the same `resolveCliJsonPaths` for `browser.executable_path`, and the same `browserScenarioSchema` refinement. Duplicate or reserved step IDs, duplicate secret identities and environment-variable names, undeclared secret references, request-step violations, and unknown fields are therefore rejected here with the same field paths capture reports, so a correction made here is the correction capture needs. Failures reuse `analysisInputErrorFromIssues`, so the reported operation stays `capture_browser_scenario`. Deliberately not included: no new MCP operation (CLI-only command); no read of secret environment variables, so a scenario whose declared variables are unset still validates, because the missing-value failure belongs to capture; no check that the browser executable or CDP target exists on the host. The scenario contract itself (`src/domain/browserScenario.ts`) is unchanged. ## Contract and boundary impact - Semantic owner and earliest changed stage: the CLI adapter boundary (`src/cliBrowserScenarioCommands.ts`); the scenario contract owner is untouched. - Contribution scope fit and linked maintainer decision: not applicable — this stays inside the existing CLI adapter and the existing scenario contract, and involves no target execution, injection, mutation, or protection recovery. - CLI and MCP/tool-catalog contract: adds `validate-browser-scenario` to `CLI_COMMANDS`. No MCP tool, no catalog operation, no input/output schema change. - Provider, bridge, target-format, or platform compatibility: none. No provider is constructed and Playwright is not imported. - Evidence, artifact, provenance, or reconstruction contract: none; no Evidence is produced. - Generated metadata (`docs/public/product-catalog.json`): generated and validated by CI; not committed here. Expected effects (checked): documentation or usability only; no target interaction. ## Evidence and regression coverage - Tests added: `tests/boundary/cli/browserScenarioValidation.test.ts`, 7 cases — valid scenario, declared secrets counted without resolution, duplicate step identity, reserved initial step identity, undeclared secret reference, unknown field, unreadable input file. - Base reproduction: before this change there was no validation-only entry point; the schema was only reached after provider resolution. - Mutation evidence (each new case against one deliberate production change): constructing a provider — killed; counting only resolved secrets — killed; dropping the step-ID uniqueness assertion — killed; dropping the undeclared-secret check — killed; relaxing the strict request object — killed; disabling the reserved-step check — killed. 6/6 killed. - User-visible output: `{"valid":true,"actions":1,"secrets":0}` on success; the projected input error with field paths on failure. - Remaining proof gaps: the acceptance lane and the `dist/`-dependent catalog/identity suites were not run for this change; `--project cli-boundary` has 110 pre-existing failing files on this Windows host, verified identical on unmodified main, and this change adds one passing file and no new failure. ## Validation performed - `vitest run tests/boundary/cli/browserScenarioValidation.test.ts` — 7 passed - mutation check (6 mutations) — 6/6 killed - `npm run verify:test-discovery` — 2484 files discovered exactly once - `npm run verify:module-boundaries` — 3059 source files checked - `oxfmt --check .` — all matched files correctly formatted - `oxlint` on the four changed files — no new findings - `vitest run --project cli-boundary` — 110 failed / 34 passed / 35 skipped, against 110 failed / 33 passed / 35 skipped on unmodified main ## Compatibility, safety, and release - Breaking changes or migration steps: none; the command is additive. - Real Hopper/Ghidra, browser, or OS coverage: none required — no browser is launched and no provider is constructed. - Package or release metadata impact: `CLI_COMMANDS` grows by one entry; the generated product catalog picks it up in CI. - Security, privacy, process, or containment review: no secret values are read or printed; validation reports counts and field paths only. ## Author readiness Human owner: @z2Ace0107 - [ ] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [ ] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [ ] I declare this PR ready for initial maintainer review. ## Before merge - [ ] This PR addresses a concrete problem or an agreed enhancement. - [ ] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [ ] The PR has one focused outcome and the title follows `type(scope): outcome`. - [ ] Related issue is linked, or the reason for not linking one is stated above. - [ ] Tests cover changed observable behavior and meaningful failure paths. - [ ] Owning docs, contracts, and generated metadata are updated where needed. - [ ] User-visible CLI/MCP changes include representative output. - [ ] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-11-03 13:39:34 +00:00

closed this issue
added the
pull-request
label

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#7676

No description provided.

Rows
Columns