Repository navigation
Windows: Define issue-owned UI claims and validate scenario data #818
Description
Is your feature request related to a problem?
Windows UI evidence is not yet bound to issue-owned stable claims and a strict scenario data contract. Editable scenarios must not redefine acceptance statements or mistake data validation for runtime verification.
Describe the solution you'd like
Implement only the G1 foundation: an issue-owned claim convention, three strict version-1 schemas (scenario, authority snapshot and fixture manifest), an offline PowerShell validator, and executable functional tests.
- Document stable issue-owned UI claim IDs, proof classes and applicable states, preserving already-approved wave-2 claims and the distinction between component and whole-claim evidence.
- Require an externally supplied authority snapshot and expected SHA-256; validate issue/source/claim/criterion/state binding without trusting an adjacent PR-authored registry or self-declared approval.
- Reject malformed, duplicate/case-confusable, unknown, missing and empty data; validate exact selectors, fixture identity/files/hashes, bounded deadlines and cleanup intent with positive document/case/assertion counts.
- Observe a real behavioral RED for a callable validator accepting an invalid authority mutation, then pass positive and negative functional cases; register the tests in the existing ValidationRunner entry point and test scenario-path classification.
- Report only valid data, never verified UI claims. No UIA execution, WinApp installation, desktop use, product edits, screenshot/golden/visual CI, TDD extension or replay implementation in this slice.
Proposed scope is six new files under windows-tests/ui-scenarios and Tools/windows, plus one test-registration call in Tools/windows/Tests/ValidationRunner.Tests.ps1 and explicit path cases in Tools/ci/tests/classify-changes.test.sh. The classifier itself, workflows, live gate, product code and Tools/tdd remain unchanged.
This is a pure tooling contract issue, not a new Windows UI surface: its implementation checklist does not invent UIA proof claims. Tests use explicitly synthetic UI claim data. Runtime verifier G2 and UIA-only replay/opt-in TDD G3 are separate issues/plans; G3 also waits for the card and sidebar changes to merge.
Describe alternatives you've considered
Trusting scenario-authored criterion/proof/approval fields would let the scenario weaken its own requirements. An empty discovery or green CI job without an executed new test is not a validation result. Building the verifier/replay in the same PR would obscure the authority boundary and expand the review unnecessarily.
Additional context
Lane-G planner pg supplied a source-derived read-only plan at accepted main 9e6d13c and rated the shared authority/proof foundation highly complex. The coordinator must approve exact file leases before implementation. G2 has a separate version-compatibility hold: the proposed official WinAppCli v0.5.0 does not yet have established workflow-ID/sandbox support; no installation or runtime preflight is claimed. Existing A-E plans and evidence remain intact. No golden images, screenshot pipeline or visual gating in CI is queued.
Activity
coneilen commentedon Oct 14, 2026
Implementation plan (wave 2)
Lane G, G1: issue-owned UI claim convention and offline scenario validation.
Tracker: #818
Status: SOURCE REVIEW ACCEPTED IN PRINCIPLE; planning-only pending recorded
public coordinator approval.
Planning worker: pg. Date: 2026-10-14.
Repository/source baseline: 9e6d13c
(local HEAD and origin/main at the time of inspection).
This plan is not an issue-owned UI claim registry and does not allocate UI
claim IDs.
Coordinator disposition and remaining handoff
The coordinator's source review accepted G1 in principle: an issue-owned UI
claim convention, strict JSON data contracts, an offline validator and
functional validator tests, with the six new files and two exact existing
test edits below. The proposed hard limits and external-authority hash contract
are accepted without any runtime or approval guarantee.
G1 itself is pure data tooling, not a Windows UI surface. The allocated tracker
uses an ordinary implementation-contract checklist, not fabricated semantic/
UIA claim IDs or proof classes for the offline validator. Synthetic test claim
IDs are explicitly fixtures. Obtain recorded public coordinator approval,
then start one implementation session and one PR. Stay planning-only until
then. Do not start G2 or G3 as part of G1.
Complexity: highly complex, despite the deliberately small first PR. G1
introduces a shared mechanism governing many surfaces: the boundary between
issue authority, editable scenarios and admissible proof. Duplicate JSON,
cross-document binding, incomplete mixed claims and vacuous success are
correctness concerns, not just documentation. Select gpt-6.1-sol, high,
long_context under the canonical kickoff; the coordinator confirmed reviewer
claude-sonnet-5.5, high.
This does not justify a generic framework, runner, agent or CI redesign in G1.
The repository was kept read-only. No bootstrap, installation, build, native
test, desktop operation, workflow run, issue-body edit or PR creation was
performed. This comment publishes the source-derived plan; proposed commands
and expected REDs below are plans, not executed evidence.
Governing sources and current gaps
Read in full: origin/main:investigation/windows-parity-lane-kickoff.md,
CONTRIBUTING.md, AGENTS.md, and
investigation/windows-parity-orchestration-plan.md. The origin/main kickoff
was read with git show rather than trusting an older local copy. The initial
planning artifact stayed local until this tracker was allocated; this comment
is the public corrected plan for coordinator approval.
Source observations:
No .github/agents directory or windows-tests/ui-scenarios directory was found
in this baseline. No product or shared Swift change is necessary for G1.
No macOS or Windows image was opened or recaptured: G1 changes no UI and this
plan makes no visual finding. Issue bodies, authoritative claim comment and
current plan-approval comments were read remotely; product source is cited
below only to ground the nonbinding A-E mapping and later execution limits.
G1 acceptance boundary
Put these ordinary implementation contracts on the new G1 issue as acceptance
checklist items. They are not Windows UI claims and receive no fabricated UI
proof classes or UI-CLAIMS declaration:
meanings, allowed proof class and applicable states before new UI work starts.
Scenario authors cannot rename, weaken, split away or close those claims.
and version, exact-selector declarations, bounded waits and cleanup intent
offline. Reject unknown, malformed, duplicate, missing and empty data.
positive executed counts and a real behavioral RED for an acceptance rule.
positive-structured-count edit accepted in principle below, after the public
plan and recorded tracker approval.
input, rendering, persistence, parity and issue closure.
G1 creates no real product claim-id.json file. Synthetic data exists only in
the test's disposable scratch. Empty production discovery must fail, not pass
as "nothing to validate." Real scenarios are authored only after independent
verification and human review. No actual UI-claim declaration is needed in a
G1 PR body; the unchanged TDD contract applies.
Exact G1 file scope
New files, within the proposed lane-G areas:
Existing-file leases accepted in principle; not active until recorded tracker approval:
No edit to Tools/ci/classify-changes.sh is necessary: its existing ancestor
patterns already cover these files. No workflow edit is requested for G1.
If either registration lease is declined, report the exact missing CI coverage
and obtain a revised plan; do not silently publish an unregistered green suite.
Not leased: App.zig, AccessibilityProvider.cpp, GraphModel.zig, NativeForms.zig,
GraphStore.swift, any product/shared Swift file, existing uia-live-gate.ps1,
validate.ps1, windows-shell.ps1, WindowsShell.Tests.ps1, any Tools/tdd file,
any workflow, kickoff/orchestration/ledger files, or any extra skill directory.
Future edits to any of these need a named coordinator approval and the slice
that owns them. G1 needs no desktop or Sandbox lease.
Authority and proof contract
An issue claim has an immutable ID such as 768-C3, an exact acceptance statement,
an issue-owned proof class (semantic-uia, visual, input or mixed), and state
applicability. Record success, empty, error, disabled,
persistence-after-relaunch and keyboard as required or not applicable with a
reason where relevant. Do not add new states to already-approved A-E work.
Do not recycle an ID after its meaning changes: the owner must explicitly
supersede it and issue a new ID.
The validator requires -AuthorityPath and -AuthoritySha256 from its caller.
There is no default authority file taken from the PR head. The trusted
coordinator supplies a frozen snapshot outside the untrusted checkout:
schemaVersion, repository, issueNumber, source URL/comment ID, sourceUpdatedAt,
sourceBodySha256, and nonempty claims with ID, exact criterion, criterionSha256,
proofClass and the six state-applicability entries. Digests use exact UTF-8
bytes without undocumented newline normalization. Each claim's numeric prefix
must match its issue; the source URL/comment and repository must match too.
The CLI verifies snapshot bytes against the separately supplied expected hash,
then validates scenario authority references against that snapshot. A scenario
contains claimId and authoritySha256, not editable acceptance text, proofClass,
or approval/verdict fields. A PR cannot authorize a weakened criterion by
editing its own scenario and an adjacent registry file.
Technical limit: a matching hash establishes byte identity relative to a
caller-supplied value, not that an issue owner approved those bytes. G1 neither
authenticates GitHub roles nor parses arbitrary Markdown into authoritative
claims. The coordinator must compare the export with the issue and supply the
trusted hash. A later CI caller must not read both trust inputs from PR head.
An approvedBy or reviewed:true field would not enforce human review; omit it
instead of creating that appearance. Human approval is an actual review event.
Proof classes are not interchangeable:
Schema acceptance is reported as "valid data", never "verified claim".
Only later evidence records use verified/failed/unverifiable; a scenario
document cannot self-declare a verdict. Mixed/component scenarios explicitly
list uncovered required states/proof components in the validator report.
Scenario and fixture schema v1
Use additionalProperties:false on every object; exact enums, types and
minItems/minLength/maxItems/bounds rather than truthiness/default coercion.
Unknown schemaVersion, mismatched fixtureVersion, nulls, booleans-as-numbers,
empty required strings and case-confusable property names are refusals.
Expected empty text is legitimate only as an explicit typed Value/Name assertion,
not a default produced by a failed read.
One file per claim: windows-tests/ui-scenarios/issueNumber-Cn.json.
CLI selection is -ScenarioRoot plus optional exact -ClaimId values.
Fail on unknown/duplicate requested IDs, mismatched file/claim identity,
duplicate claim files, an empty selection, or missing requested scenarios.
Only the three named schema files and fixtures subtree are non-scenario JSON.
Do not quietly ignore an unexpected JSON file.
Required scenario fields:
Targets declare a literal, case-sensitive AutomationId, expected controlType and
owned root/owned-modal scope with matchCount fixed to 1. No regex, index=0,
Name fallback, wildcard, "nearest invokable ancestor" or slug-only selection.
G1 checks this declaration, not actual runtime uniqueness. A later runtime must
re-resolve and check exactly one current matching element immediately before
action, including PID/HWND/process-generation ownership. Missing required UIA
cannot be repaired with a coordinate click or Win32 command.
Version 1 accepts no coordinate field at all. This is intentionally stricter
than "coordinates only in input/visual tiers": no coordinate replay is needed
for the first slice. A later separately approved input-tier extension may add
owned in-bounds coordinates; no visual tier or screenshot operation is reserved
or queued here. Drag/pan/zoom are local interactive evidence, not G1 operations.
No screenshot/golden/pixel-baseline path, expected image or visual threshold is
part of these schemas.
Suggested hard limits to approve with G1: UTF-8 documents at most 1 MiB,
depth at most 32, 1-16 cases, 1-128 steps per case, 1-128 expected assertions,
ordinary step/wait deadlines 1-10000 ms, relaunch readiness 1-30000 ms,
cleanup 1-15000 ms, case budget at most 60000 ms and total scenario budget at
most 180000 ms including cleanup. Reject fractional/negative/zero/excessive
values and internally impossible aggregate budgets. These are validation
bounds, not a promise that UIA/COM calls are cancelable; G3 needs a supervised
worker process to enforce wall-clock limits on hung COM.
Fixture manifest fields: schemaVersion=1, fixtureId, positive fixtureVersion,
nonempty files with relative data paths and sha256. Validate the scenario's
manifest hash, matching ID/version, positive file count and every file hash.
G1 proves the declared fixture revision matches its manifest; it does not
prove a future executor supports that revision. G2/G3 must reject fixture
versions unsupported by their actual setup adapter. Reject duplicate files,
unknown schema versions, missing files, absolute/traversal/
device/alternate-stream paths and reparse-point escapes. Fixtures contain
privacy-safe owned data only. Creating production state later must use normal
supported profile/CLI/daemon paths, not installUiaFixture or private messages.
G1 does not invent a real production fixture or run its contents.
Creator-directed future G2/G3 canvas-ID strategy (2026-10-14): canvas-card
suffixes are derived from identities including project paths. Use a documented
fixed canonical PROJECT fixture root identical locally and in CI, for example
C:\gcfx\fixture-id, not a unique per-run project path. Acquire an exclusive
lock first; verify the target is absent or empty AND positively owned. Refuse
foreign, nonempty, unowned or reparse paths; do not treat absence/emptiness
alone as ownership. Clean up only the resolved owned fixture child and verify
cleanup. Support directory, daemon pipe, temp and transcript runID remain
unique per run.
Scenario selectors are exact AutomationIds actually observed under that
canonical root, explicitly NOT portable across roots. Do not guess a hash,
use a wildcard/Name/first-match fallback, or add a discovery resolver to hide
root changes. Root-independent logical UIA identity would require a separate
product issue, not lane G. Runtime lock/ownership/capture behavior remains
unproved until G2/G3 implement and exercise it under their approved plans.
This execution-root decision is separate from G1's offline packaged fixture
data location, manifest identity/version and hash validation. G1 adds no
canonical-root creation, lock, executor, identity resolver or WinApp preflight.
Validator functions and implementation order
Keep one script, not a new module/package hierarchy:
Reject exact and case-confusable duplicate object properties recursively
before any PowerShell conversion can overwrite them. Reject malformed JSON,
unsupported depth, arrays/scalars at document root and unreadable paths.
with built-in Test-Json, without external reference resolution. Return
explicit document/field/error codes; never continue with a default object.
ID/source/criterion binding, proof-class compatibility and state coverage.
An implementer-authored applicability change is not authority.
fixture version compatibility, manifest identity/hash and file hashes.
Perform no mutation or setup.
operation/target/property checks, deadline sums and coverage summary.
Return nonzero validated document/case/assertion counts.
nonzero with bounded actionable errors. Emit one machine-readable summary
with schema/authority/fixture hashes, selected IDs, counts, coverage and
uncovered requirements. No UI verdict, arbitrary JSON dumps or full
environment contents.
Use helpers only where these actual responsibilities need them. The JSON
schemas are the structural source of truth; semantic cross-file checks belong
in PowerShell, not a second divergent hand-written schema implementation.
RED, GREEN and negative controls
Expected future focused command:
Start with a minimal callable parser/schema validator and the positive fixture.
Add the authority-binding test before implementing that binding: the otherwise
valid scenario carries a different issue/source revision than the trusted
snapshot and must be refused with ClaimAuthorityMismatch. Observe the actual
test fail because the callable validator accepted that mutation, not because a
file/function/package/tool was missing. Preserve this RED transcript and the
test/WIP-source hashes in separate session artifacts. This is incremental TDD
for new tooling, NOT a base-vs-head product regression claim. Missing validator
or missing PowerShell is a setup failure, not acceptable behavioral RED.
Implement the binding and rerun the identical command for GREEN. The test suite
must assert positive executed and passed counts, zero failures, and include:
GREEN is the measured count, not an anticipated test number. Each case has a
stable name; the runner rejects a discovered/executed count of zero.
After the named registration lease is approved, local regression commands:
Use pg-owned TEMP/TMP under C:\gcs\pg; do not run full unit/integration locally.
Register the new functional test through ValidationRunner as described above,
then inspect exact-head CI logs for its positive count. The classifier cases
must also pass locally. A green required check alone is insufficient evidence
that the new test actually ran. Cite run/job IDs and executed counts honestly.
Run the unchanged body checker before publishing the eventual PR. No gate
exemptions and no fabricated RED/GREEN/REGRESSION text.
G1 has no app capture/test plan: no UI changes and no runtime claims. Public
evidence is validator fixture/count output only, with owned synthetic strings.
Retain the initial failure and passing result separately, including source/
test hashes. Do not overwrite a failed log with a corrected run.
G2 dependency and bounded scope (not implementation approval)
Prerequisites: merged G1 plus a separately allocated issue/approved plan and
file leases; the exact local WinApp pin/provenance and approved local preflight
described below; an available shared desktop queue slot when exercising keys
or screenshots. G2 does not depend
architecturally on B/C merges to write the agent, but must not launch across
their final captures or redefine their approved evidence requirements.
Propose new .github/agents/ui-verifier.md and, only if needed, narrowly scoped
new Tools/windows verifier helpers/tests. Request a named existing-file lease
for investigation/windows-parity-lane-kickoff.md's claim convention and step-7
integration in G2; merely writing an agent does not change the shared kickoff.
Do not create an additional skill directory or install an upstream skill
silently. The agent must be started
in a fresh context with the owner-approved claims, exact SHA and fixture
contract, not the implementer's explanation of why it works.
Phase A:
untracked product inputs; production ReleaseSafe shell and release daemon/
CLI with pinned Zig/Swift/providers. No Debug/test-only build, --smoke or
--stress. Build in its own roots and record exact commands and provider pins.
allowlist/scrub, isolated real support/profile/temp directories, normal
isolated production daemon endpoint and real persisted fixture setup. Confirm hooks absent in
the child, not merely deleted from the parent. Record tool/exe hashes,
Git SHA, production flags, OS/session/DPI, fixture schema/version/hashes,
allowed environment and all commands with exit status/time bounds.
inspect/search/invoke/send-keys/wait-for/screenshot with --json, explicit
owned HWND/PID and a verifier-owned transcript runID. Use a unique support
directory, production daemon pipe and temp per run, the exclusively locked
fixed canonical project fixture root described above, plus verified owned
zmx cleanup. Do not require WINAPP_UI_WORKFLOW_ID or --on sandbox in
this pin. Treat search as discovery only: verify exact
AutomationId/property/control type/count and ownership before action.
Refuse slug/substring or automatic invokable-ancestor substitution.
scope. Missing required UIA for semantic/input/mixed is failed, not waived
by pixels or a private command. Harness/tool/desktop unavailability is
unverifiable with the failure retained; it is never a passing claim.
Visual claims require actual opened screenshot evidence; a UIA bounding
rectangle or screenshot file path alone is not proof.
before Phase B reads the diff. Do not use the diff/source to choose a
hidden bypass during black-box exploration.
Phase B audits the diff/source and build path for test-only branches, new env
hooks, fixture/stub substitutions, unimplemented claims and production mismatch.
An audit can invalidate Phase A or require a rerun; it cannot convert a missing
observation into success. Agent outputs are exploratory evidence, not the
source of truth. Failures return to the implementer without editing the issue
claim definition. Human review checks the eventual scenario and claim mapping.
Use the existing local visual-review kickoff step 7 and ONE shared-desktop
slot, after code review and exact-head CI on the final head. Merge verification
and screenshot review into that slot; never queue a second slot for G2.
Request at most 15 minutes and list the exact surfaces/states beforehand.
If it does not fit, narrow the slice or report unverified states; do not skip
the gate or take extra desktop time. Retain existing approved A-E evidence;
no retroactive new tool/scenario/verifier or recapture requirement.
Cleanup: prefer File > Exit, record each owned process with PID, creation time,
exe path/hash and root, verify identity before stopping by PID, include owned
zmx descendants, and verify none remain. Never stop another session's process.
Keep fixture roots for intentional relaunch until that assertion completes;
then delete only resolved owned subdirectories. Retain evidence on failure.
No foreign-window titles/tree contents or full-screen capture. WinApp WGC
composition/screen fallback must satisfy the existing ownership/privacy/pixel
checks; the tool's success alone is not a capture lease or privacy guarantee.
Evidence manifests are content-addressed and retained by run ID; raw failed
attempts are not replaced. Hashes detect mutation but do not create WORM
storage, trusted execution, or an attestation by themselves. Publish only
privacy-reviewed synthetic fixture output; no credentials or prohibited bundles.
Production environment inventory for G2
App.zig at this baseline contains 22 distinct GRAPHCODE_* string literals.
The 17 hook names below are the relevant production hook inventory, not a
promise that scrubbing only two UIA variables is enough:
Clear all of these. Additional source-derived settings are not all test gates:
(App.zig:480 and production stores). Keep it only as an explicitly owned,
recorded fixture root; onboarding-seen belongs there. Isolate USERPROFILE,
LOCALAPPDATA, APPDATA, HOME where used, and TEMP/TMP process-only.
GRAPHCODE_WORKSPACE_LAYOUT are the other App string names (layout appears
in App tests and is read in production TerminalSurface.zig:810).
Use the coordinator-directed unique per-run production daemon pipe with
matching real shell/daemon configuration, bundled zmx, owned cwd and default
layout, not private gate roots or stub paths. Record the owned pipe/support/
fixture identity mapping. A necessary production override must be declared
and prove no test shortcut; do not blanket-call isolation a failure or
silently keep a behavior-changing override.
GRAPHCODE_UIA_DAEMON_COMMAND_LOG (DaemonClient.zig:815);
GRAPHCODE_WORKSPACE_PROJECT and GRAPHCODE_SHELL_NONREADING_ATTACH
(TerminalSurface.zig:567-573,2805);
GRAPHCODE_SHELL_SESSION_PREFIX (WorkspaceLayout.zig:129/ZmxSession.zig:36);
GRAPHCODE_EXPERIMENTAL_TERMINAL_VT (TerminalVt.zig:32 and shell README);
GRAPHCODE_GH (Codespaces.zig:374); GRAPHCODE_VERSION
(WindowsUpdates.zig:170). Clear defaults/rollback/fake-tool overrides rather
than silently changing the configuration being verified.
GRAPHCODE_WORKTREE_TEST_* from production reads; do not claim a literal
count proves all code paths are scrubbed. Allowlist child environments and
Phase-B re-inventory make unknown inherited test gates ineffective.
Build tools may need SDKROOT/INCLUDE/LIB and the pinned tool variables; that
does not authorize inheriting the same environment into the production app.
Never dump the host environment or credential-bearing PATH/config contents
into uploaded logs.
Official WinApp evidence and creator-directed compatibility decision
Official release v0.5.0 exists. Release API reports source commit
fd7cb6f235fa54dd2c6e26386e65e967a2c8797a and published 2026-07-20.
The official project describes the CLI as Public Preview, although the release
API's prerelease flag for this tag is false. Do not confuse those two labels.
Creator-directed exact local G2 pin, not installed or preflighted in G1:
winappcli-x64.zip, release API digest
88735ce6c2582ac5fac6200194bf62467fdd72b44b2d230f3a4ed059fa79ee7d.
G2 must recheck the official asset/digest and executable version/hash before use.
Do not silently use 0.7.1/latest, add the CLI to bootstrap, or install it in CI.
Official versioned sources inspected:
Relevant confirmed API: explicit -w HWND; inspect --json nests elements under
windows[]; search/wait-for return element arrays, not the same envelope.
get-property exposes AutomationId (service:702-708). invoke tries Invoke,
Toggle, SelectionItem then ExpandCollapse; command success is not proof of the
required pattern/action. wait-for has --timeout in milliseconds, --property,
--value and --gone. send-keys defaults to post-message; --via send-input is
OS injection, not physical input. JSON warnings and actual end state must be
checked even with exit 0.
Source-only compatibility finding: v0.5.0 docs, UiCommand.cs and Program.cs contain
no WINAPP_UI_WORKFLOW_ID reference; its complete, non-truncated 1166-entry tree
has no sandbox/desktop-coordination paths. That is evidence of missing
documented support, not a runtime capability test. Newer default-branch docs
do describe workflow-ID coordination and sandbox features; they are not
v0.5.0 evidence.
Future G2 decision, received through the creator on 2026-10-14: keep the
exact official v0.5.0 source/asset pin above; no silent upgrade. Drop unsupported
WINAPP_UI_WORKFLOW_ID and --on sandbox requirements. Isolate each run using a
unique support directory, real production daemon pipe and temp, a verifier-owned
transcript runID, and verified owned zmx cleanup. The subsequent creator-directed
canvas strategy fixes the PROJECT fixture root identically local/CI under an
exclusive lock and positive ownership checks, rather than varying the project
root per run. These identities and locks do not replace the coordinator's
single shared-desktop queue.
Before verifier logic relies on this CLI, the G2 planner must obtain approval
for and perform a LOCAL preflight proving pinned ui inspect, invoke, wait-for
and screenshot against an owned GraphCode Win32 window. Desktop-affecting
preflight uses the same one-slot queue; never take an additional concurrent
slot. Record pin/tool/exe hashes, actual JSON shapes, ownership, command
results and the observed end state. Source documentation alone is not runtime
support. No G1 installation or preflight is permitted.
Sandbox qualification remains separate: one Sandbox per host; vGPU-disabled
guest 1520x823 and unreliable EnumDisplaySettings establish clean-state UIA
only, not visual parity. No --on sandbox CLI dependency, fallback tool
installation or version upgrade is authorized.
Other G2 holds: prove local screenshot capture safety under the existing gate,
exact-owner behavior of each CLI envelope, warning/error handling, production
fixture setup and canonical-root lock/ownership/cleanup execution before
claiming replay readiness. The canvas-ID strategy is decided, not runtime
verified; exact observed IDs apply only at the documented canonical root.
None was executed during this planning pass.
G3 dependency and replay/opt-in contract (not approval)
G3 requires merged G1 AND G2, lanes B/#764 AND C/#767 merged, actual
human-reviewed production scenario files, and a separately approved issue,
plan, workflow/runner/TDD leases and result-delivery design. Do not wire an
empty scenario directory, synthetic contract fixtures or WinApp CLI into CI.
Proposed new Tools/windows/uia-scenario-replay.ps1 and
Tools/windows/Tests/UiScenarioReplay.Tests.ps1 use native UIA properties and
Invoke/Toggle/Selection/focus/value/waits, in a supervised bounded worker.
Reuse the existing gate's approaches; never dot-source, rewrite or edit it.
No AI or WinApp installation in CI, no screenshots/goldens/pixel comparisons.
interactive cases are local-only; they must be reported as not replayed, not
silently counted in CI's passing totals. At least one real eligible scenario,
case, action/observation and assertion must execute positively.
Required runtime negative controls: zero/two exact IDs, foreign/reused PID,
wrong root/owner/class/control type, stale root requiring reacquisition,
missing/unsupported pattern/property, timed-out/hung COM, denied invocation,
UIA absence, missing fixture state, no-op action, wrong final state, zero
selected scenarios, malformed result, cleanup failure, old exe/hash/SHA,
unmatched/missing/duplicate declared ID and incomplete transcript. Expected
absence needs a successfully resolved positive anchor and live owner.
Property retrieval exceptions never become empty values.
Canvas identity/selection/invoke/focus use canvas-card Buttons, including
supported selection patterns/properties despite Button control type. Replay
uses the same documented fixed canonical project fixture root and exclusive
lock/positive ownership/refusal/cleanup checks as G2; its exact observed
selectors are not portable across roots.
Geometry, edges and clipping need local screenshots; drag/pan/zoom need the
interactive tier. Existing native-menu HMENU evidence does not become UIA
evidence. Do not change the product/live gate to make a replay pass.
TDD extension is opt-in only by one exact top-level declaration, proposed
UI-CLAIMS: id1, id2 outside comments, fences and quoted examples. Mentions,
links, examples and ordinary RED/GREEN lines do not opt in. Empty, malformed,
duplicate or unknown declarations fail explicitly; no declaration preserves
all current unrelated-work behavior and tests, including template rejection.
The implementer cannot author new meanings for declared IDs.
Proposed Test-TddEvidence.ps1 future inputs include trusted authority,
scenario-result manifest and expected head SHA. A declared ID must map to its
reviewed scenario/hash, all required replayable cases passing on that exact
head, a production-config/exe/fixture/environment receipt, positive counts and
successful cleanup. A mixed claim's passing UIA component is not whole visual
claim closure, and no visual result becomes a CI gate.
Workflow design must be approved separately before G3 implementation:
the current TDD workflow has only PR-body input and triggers on body edits;
the shell workflow does not share replay artifacts with it. Default checkout
can test a PR merge commit rather than the actual PR head. Resolve authenticated
same-head result transport, correct reruns after explicit declaration edits,
pending/failed result handling and exact-head checkout/build provenance.
Do not accept a body-authored pass assertion or self-uploaded JSON as trusted
passing CI. Do not make a syntax-only first phase masquerade as the declared
claim mapping gate. These are real remaining design obligations, not a G1
implementation task.
Expected requested G3 leases, to be named/reviewed after B/C land:
Tools/tdd/Test-TddEvidence.ps1, its existing Tests and README;
.github/workflows/windows-shell.yml integration/result upload only;
.github/workflows/tdd-evidence.yml if needed by the approved transport design;
Tools/windows/validate.ps1 and ValidationRunner.Tests.ps1 only if the approved
integration point requires them; and a separately approved follow-up to the
canonical kickoff's opt-in CI instructions, preserving G2's step-7 integration.
No workflow, runner, test-registration or kickoff approval is
implied by listing these paths.
G4 and excluded work
G4 base-versus-head RED is later, only for affected/declared claims. Same
trusted scenario, fixture, production configuration and reachable target state
on base and head. Base must reach the actual intended assertion and fail it.
Build failure, missing API/fixture/tool, different state, selector mismatch,
timeout before target or zero tests is not regression RED. Unaffected claims
need not be rerun on base. Preserve both attempts and provenance.
No visual CI lane is queued. No golden images, screenshot pipeline,
pixel-baseline comparison, visual gating or revival of cancelled lane F.
Existing visual contracts/gates remain untouched; this plan does not exempt
product lanes from their current local code/CI/image-review gates.
Existing A-E claim mapping for coordinator review only
These proposals preserve original checkbox order and whole-claim wording,
including deferred parts. They do NOT amend approved plans, allocate official
IDs, require a new verifier/scenario or demand recapture from A-E.
A/#768 is already authoritative:
#768 (comment)
PR #808 merged as the planning baseline SHA; accepted text-prompt/native/
geometry evidence is scoped and does not close ANY whole 768 claim. Do not
replace these IDs, narrow them to GraphCodeWindowsDialog, or reinterpret their
classes. NativeForms and remaining visual/input states are still deferred.
Coordinator approval comments consulted:
B 6171381827; C 6171381818; D 6171381897; E 6171381948.
These existing issue-owned rulings, not this proposal, control implementation.
Grounding for mappings, not new parity findings:
unwired actions are at 128-152,250-277. Windows GraphCanvas.zig:1655-1730
draws the current card; DesignTokens.zig:102-103 remains 250x106 at this
baseline. Lane B owns that gap, not G1.
open-loop-before-project selection and list composition. Windows
Sidebar.zig:167 onward and App.zig:7509-7710 generate current paint/UIA.
Conditional extras and selection need their own evidence, not a broad count.
LoopWorkspaceLoopBar.swift:40-59,113-138 has identity/progress/actions.
Windows App.zig:7690 onward still references workspace_is_quick_chat at
this baseline; TerminalSurface.zig owns workspace binding. Preserve lane
D's approved derived-bound-identity fix rather than adding another flag.
expose Stop/transfer actions. Windows GraphContextMenu.zig:49-90 lists
current supported actions. Missing transfer implementations and native-menu
UIA limitations are not a schema problem and cannot be silently papered over.
No checkbox should be ticked or ledger row promoted from this mapping. Assign
the remaining A-E IDs only at verification under the coordinator's exception,
using the existing evidence and acceptance boxes.
Roots, leases and handoff
pg roots if later approved execution needs them:
C:\gcs\pg scratch/logs/TEMP/TMP, C:\gct\pg tools, C:\gcp\pg providers,
and C:\gcpg as a REAL validation directory (7 characters total, no junction).
Nothing was installed or executed there for this plan.
Before implementation: obtain recorded public coordinator approval on #818 for
this ordinary data-tooling contract checklist, the six new files and the two
named exact test edits. The hard limits and external
authority hash contract are accepted in principle; no UI/runtime/human-approval
claim is authorized. There is no workflow lease. Start no code before that
public-plan/approval handoff, or if the coordinator narrows one of those leases.
G1 is ready for public coordinator approval. G2's exact pin, dropped unsupported
workflow-ID/sandbox requirements and fixed canonical project fixture-root
strategy are resolved as future planning decisions, not runtime proof. Local
preflight, production fixture handling and canonical-root lock/ownership/
cleanup behavior remain to be proved. G3 waits for G1/G2, B/C merges, real
reviewed scenarios and approved CI-result transport. No implementation starts
from this publication alone.
coneilen commentedon Oct 14, 2026
Plan approved (coordinator): G1 only
Approved plan: #818 (comment), with the bounded authority/data-validation scope and corrections below. This is not approval for G2/G3/G4, UI execution or a visual pipeline.
Six new files approved: windows-tests/ui-scenarios/README.md; scenario.schema.json; claim-authority.schema.json; fixture.schema.json; Tools/windows/Test-UiScenario.ps1; Tools/windows/Tests/UiScenario.Tests.ps1.
Exact existing-file extensions approved: Tools/windows/Tests/ValidationRunner.Tests.ps1 gets one child invocation of the new functional test and an explicit positive structured execution/result-count check immediately before its final PASS. No other contracts, gate assertions, helpers or their counts are rewritten. Preserve A's accepted lookup/hit cases and all subsequently accepted B/C/E changes on rebase. Tools/ci/tests/classify-changes.test.sh gets explicit scenario-schema, representative claim-file path and validator-path cases (Windows true, macOS/Linux false), preserving LF. Existing classifier ancestor coverage was checked; do not edit classify-changes.sh. I confirmed current Windows port CI executes ValidationRunner, so the registration is real rather than assumed file discovery.
Not approved: product/shared Swift, uia-live-gate.ps1, validate.ps1, windows-shell.ps1/WindowsShell.Tests.ps1, workflows, Tools/tdd, kickoff/orchestration/ledger, agent/skill files, tool installation or native/desktop/Sandbox execution. No real product claim-id.json is added; production discovery of zero scenarios is an explicit failure, not a pass. G1 is pure tooling: its ordinary implementation checklist must not manufacture UIA proof claims for the offline validator itself; synthetic IDs in disposable test fixtures are clearly synthetic. The existing TDD evidence contract remains unchanged and G1 need not declare UI-CLAIMS.
Approve the external AuthorityPath plus independently supplied AuthoritySha256 contract, no default PR-head authority, strict draft-07/local-only schemas, recursive duplicate/case-confusable-key checks and explicit cross-document/selection/fixture/path/hash/version/coverage/deadline errors. Schemas are the structural source of truth; do not build a divergent second schema. Hash matching proves byte identity relative to the caller, not human approval or runtime truth. Valid data must never be reported as a verified UI claim. Mixed/input components cannot close visual/physical/uncovered requirements.
Approve documented bounds: 1 MiB UTF-8 document, depth 32, 1-16 cases, 1-128 steps and expected assertions, ordinary deadlines 1-10000ms, relaunch 1-30000ms, cleanup 1-15000ms, case budget at most60000ms and scenario at most180000ms including cleanup; reject impossible aggregate budgets and wrong types. No coordinate/visual replay in v1, remote refs, arbitrary commands, input execution or fixture setup. Only safe owned fixture reads and validator test scratch.
Required evidence: preserve a real incremental behavioral RED where a callable otherwise-valid validator accepts a wrong authority mutation before the binding rule, not a missing file/API/parse failure. Then run the identical functional command with positive case counts and all named negatives, including duplicate/empty/unknown selection, canary non-execution/no secret-error leakage and path/reparse refusals. Run ValidationRunner, classifier tests and unchanged TddEvidence.Tests locally; assert the NEW child test actually executes with its own positive count, not inherited protocol counts. Exact-head CI and different-vendor code/evidence acceptance remain mandatory. G1 has no screenshot claim or desktop slot.
Model: highly complex as rated by the planner: a new shared authority/proof boundary across many future surfaces, with duplicate JSON, cross-document and vacuous-success hazards. Implementer gpt-6.1-sol/high/long_context; reviewer claude-sonnet-5.5/high. Worker ig owns C:\gcs\ig, C:\gct\ig, C:\gcp\ig and real C:\gcig; never another lane's build/scratch.
Future decisions that supersede older G2 text: exact official WinAppCli v0.5.0/fd7cb6f2, x64 archive digest88735ce6c2582ac5fac6200194bf62467fdd72b44b2d230f3a4ed059fa79ee7d; no silent upgrade and no undocumented WINAPP_UI_WORKFLOW_ID/--on sandbox requirement. G2 must separately preflight inspect/invoke/wait-for/screenshot on an owned GraphCode Win32 window before logic relies on the pin. Canonical project fixture root is fixed identically local/CI perfixtureID, exclusive-locked, verified absent/empty and owned, with scoped cleanup; support/pipe/temp/runID remain unique. Literal IDs are observed there and NOT claimed portable across roots. These are future executor requirements, not G1 implementation. No root-independent product-identity change, WinApp installation in CI, screenshot/golden/pixel-baseline/visual CI, or extra A-E verifier/slot. G3 requires G1/G2, B/C merges, real reviewed scenarios and separately approved opt-in TDD/result transport/wiring.
Validate offline UI scenario data against issue-owned authority
coneilen commentedon Oct 14, 2026
Completed the five G1 infrastructure criteria in #820, merged as6916bc2c2baabc2f83c92230aeee8b49e879758e after exact-head26 completed checks (24success/2intentional skips), source/evidence acceptance and actual166/166/0 offline contracts. The callable wrong-authority RED and original startup/SDK CI failures remain retained separately from their successful exact-job retries. This closes the data-contract issue only: no UI runtime, human approval, physical input, parity or product claim is established. G2 uses the same central driver under a separate tracker/plan/installation/native-preflight approval; no unsupported workflow-ID/sandbox requirement or silent pin upgrade.