# 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 | Local | Visual | Transaction boundary | Macro witness | Completion claim | |---|---|---|---|---|---| | Traditional Stage 0 | PASS | NOT MEASURED | NOT MEASURED | NOT MEASURED | **COMPLETE — false green** | | Dynamic Stage 0 | PASS | FAIL | FAIL | FAIL | INCOMPLETE | | Dynamic Stage 1 | PASS | PASS | PASS | FAIL | INCOMPLETE | | Dynamic Stage 2 | PASS | PASS | PASS | PASS | **COMPLETE** | ### Stage 0 — conventional false green The original unit suite ran only local happy-path checks: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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 ```text CONTROLLED FEASIBILITY TEST: PASS ``` The decisive observation was Stage 1: ```text 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.