Dynamic Global Observation PoC — Experiment 01

False-Green Checkout Benchmark

Date: 2026-09-16
Purpose: Test whether Series A + Series B can prevent false completion and guide targeted cross-perspective repair in a controlled software task.

作者： Neo.K
機構： EveMissLab／一言諾科技有限公司
版本： 原稿未標註（本次整理版）

Intent contract

1. Quantity is 1–5; total is qty × 100.
2. On a 390×844 mobile viewport, Purchase must be fully visible and actually clickable.
3. One user purchase intent must create exactly one order under rapid double-click / duplicate submission.
4. Confirmation must reflect a real successful server order.
5. Public endpoint remains POST /api/order.

Security hardening, production load, and accessibility certification are explicitly out of scope for this round.

Result

Stage 0 — conventional false green

The original unit suite ran only local happy-path checks:

2 passed

A conventional code → tests → done path therefore declared COMPLETE after one evidence channel.

Dynamic closure activated only the perspectives demanded by the intent contract. It found:

• browser hit-test at the button center returned cookieBanner; Playwright could not click the Purchase control;
• two submissions carrying the same intent_id created 2 orders.

Thus:

Local PASS
Visual FAIL
Transaction Boundary FAIL
Macro Witness FAIL

This is a controlled instance of Local Green != Macro Closure.

Stage 1 — first targeted repair

Only the two evidenced responsibility layers were repaired:

• layout / stacking;
• server idempotency for duplicate intent_id.

After that:

Local PASS
Visual PASS
Transaction Boundary PASS
Macro Witness FAIL

This was the strongest result in the experiment.

The actual browser-level rapid double-click still produced:

orders_created = 2
confirmation = "Order #2 confirmed"

The reason was cross-boundary semantic: the browser generated a new intent_id per click. The server correctly deduplicated identical keys, but the UI did not preserve one user purchase intent across the rapid double-click window.

So two lower-level greens still did not imply the user-level macro relation was closed.

Stage 2 — intent ownership repair

The client was changed so rapid clicks in the same purchase-intent window reuse the same intent_id.

Final rerun:

Local PASS
Visual PASS
Transaction Boundary PASS
Macro Witness PASS
orders_created = 1
confirmation = "Order #1 confirmed"

Only here was COMPLETE issued.

What the methodology actually contributed

The useful behavior was not “more review.” It did four concrete things:

1. kept local test success scoped as Local Closure, rather than promoting it directly to global completion;
2. activated only requirement-relevant perspectives instead of all roles;
3. reopened affected closure dimensions after repair, instead of restarting an unbounded ceremony;
4. used a Macro Witness as a relation-level falsifier, which exposed the Stage-1 bug after local visual and transaction checks were already green.

Evidence cost

Traditional Stage 0 used one local evidence channel and produced a false completion.

The dynamic experiment used four targeted closure channels:

implementation
visual
transaction boundary
macro witness

It did not activate unrelated security, performance, database, architecture, or multi-agent review paths.

What this supports

This controlled PoC supports initial feasibility of:

Green != Done
Local Closure != Macro Closure
Perspective selection can be intent-conditioned
Cross-boundary semantic failure can survive local PASS states
Macro Witness can expose failures local tests miss
Completion can be tied to relevant closure topology

It also gives a concrete working form of:

Global Mind + Local Lens

What it does not prove

This is one deliberately constructed synthetic scenario. It does not establish universal superiority, routing accuracy on arbitrary repositories, or general cost savings.

The appropriate conclusion is:

Controlled feasibility: POSITIVE
General empirical validation: NOT YET ESTABLISHED

A broader benchmark should include randomly hidden failure domains, larger repositories, routing false-positive/false-negative rates, wall-clock/token cost, and strong baseline workflows.

Recommended next artifact

The next step should be a small reusable Perspective Closure Runtime MVP, not a large visible-process Skill.

Minimal modules:

Intent Contract
Macro Object Card
Perspective Registry
Rule-Based Perspective Router
Evidence Adapters
Closure Ledger
Macro Witness
Completion Certificate

After that works across several cases, a Skill can be a thin wrapper:

one user request
→ silently invoke runtime
→ finished work + evidence-aware completion state

This preserves Process != Progress while operationalizing Series B.

Reproducible artifacts

The ZIP includes:

• REQUIREMENTS.md
• app_stage0.py, index_stage0.html
• app_stage1.py, index_stage1.html
• final app.py, index.html
• tests_baseline/, tests_stage1/, tests_stage2/
• experiment_compare.py
• artifacts/compare_stage012.json
• artifacts/stage0_mobile.png
• artifacts/stage1_mobile.png
• artifacts/stage2_mobile.png

Final experiment status

CONTROLLED FEASIBILITY TEST: PASS

The decisive observation was Stage 1:

Local PASS
Visual PASS
Boundary PASS
Macro FAIL

That intermediate state demonstrates why macro-object-aware, cross-perspective closure is an engineering capability distinct from ordinary local testing.