# SC HOLD — verify.html "regression" investigation (APAR-003 context)
# AT 2026-05-16 | Filed by SC | Lifecycle: ACCEPTED → INVESTIGATING → AWAITING_DIRECTION
# Mode: READ-ONLY through this report. NO MUTATION.
# Trigger: AR chat directive 2026-05-16 "This is the second time it's broken. Two options: quick redeploy / standalone JS"
# TRUTH MATTERS® · OTC: USDW · CAGE 8JSY1

## Headline

Both of AR's offered fix commands cannot execute as written, and the "regression" the eye sees may not actually be a regression. Standing down until AR confirms what the working fix actually was.

## §1 — Why neither option can run as-written

**Option (a) "quick redeploy":**
```
ssh svr01 "cp /home/datacert/public_html/verify.html /home/datacert/public_html/verify.html.bak.$(date +%Y%m%d%H%M%S) && cat /tmp/datacert-gemwallet-verify.js >> /home/datacert/public_html/verify.html"
```
`/tmp/datacert-gemwallet-verify.js` **does not exist** on svr01.dataveri.ai. Find across the entire FS:
```
find / -maxdepth 5 -type f -name 'datacert-gemwallet*'   → (empty)
find / -maxdepth 5 -type f -name '*gemwallet-verify*'    → (empty)
```

**Option (b) "permanent fix":**
```
cp /tmp/datacert-gemwallet-verify.js /home/datacert/public_html/assets/gemwallet-verify.js
```
Same `/tmp` source dependency. Same problem. Plus `/home/datacert/public_html/assets/gemwallet-verify.js` does not pre-exist either:
```
ls /home/datacert/public_html/assets/  →  datacert-i18n.js, datacert-i18n.js.bak.*, datacert-nav.css, datacert-nav.js  (no gemwallet)
```

## §2 — What actually changed in verify.html today

Backups timeline (15:34 cluster — both at 15:34:44 wall-clock):
```
17707B  a7755132...  verify.html.bak.false-success-20260516153444   (mtime 15:34:44.418)
17625B  5a9c96a3...  verify.html                                     (mtime 15:34:44.421)   ← current live
delta:  -82 bytes
```

Unified diff (`-` = current, `+` = false-success backup):
```diff
@@ -101,7 +101,7 @@
 ... [unchanged: full GemWallet retry code, waitForGemWalletApi, signWithGemWallet, signWithXaman, openWallet] ...
- (function(){const p=new URLSearchParams(location.search);
-   if(p.get('domain'))document.getElementById('domain').value=cleanDomain(p.get('domain'));
-   if(p.get('address')||p.get('walletAddress'))document.getElementById('wallet').value=p.get('address')||p.get('walletAddress');
-   enforceVerifyLogin();
- })();
+ (function(){const p=new URLSearchParams(location.search);
+   if(p.get('domain'))document.getElementById('domain').value=cleanDomain(p.get('domain'));
+   if(p.get('address')||p.get('walletAddress'))document.getElementById('wallet').value=p.get('address')||p.get('walletAddress');
+   if(p.get('verified')==='1')document.getElementById('success').classList.add('show');   ← REMOVED in current
+   enforceVerifyLogin();
+ })();
```

The 82-byte removal = the single line `if(p.get('verified')==='1')document.getElementById('success').classList.add('show');`. This flips the success UI based purely on a URL parameter (`?verified=1`) — no actual verification check. The backup is literally named **`false-success`** — meaning whoever made that backup considered the snippet a false-success display path.

## §3 — What did NOT change (sanity-check)

The GemWallet detection-and-retry code AR mentioned is **present and identical** in both versions:

```javascript
// Line 91 in BOTH current verify.html AND false-success backup:
async function waitForGemWalletApi(){
  for(let i=0;i<50;i++){
    const api=getGemWalletApi();
    if(api)return api;
    await new Promise(r=>setTimeout(r,100))
  }
  return null
}
```

Plus `getGemWalletApi`, `isGemWalletInstalled`, `getGemWalletIdentity`, `signGemWalletMessage`, `signWithGemWallet` — all intact in both versions.

`grep -c 'waitForGemWalletApi\|for(let i=0;i<50' verify.html`  → **2** matches in current (function definition + use site).

## §4 — Three possible readings — AR clarification needed

1. **Reading A — the deploy was correct, not a regression:** The 15:34 deploy intentionally removed `?verified=1`-as-instant-success because it's a fake-success path. The backup name (`false-success`) was the deployer flagging the snippet AS the bug, not flagging the deploy AS the regression. If this is right, **no mutation needed** — verify.html is in the desired state and AR's APAR-003 is based on a misread of the timeline.
2. **Reading B — the deploy regressed a different, unrelated fix:** AR may be referring to a fix that lives in a file or path I haven't checked yet (perhaps an asset file, a Webmin-managed copy, or a backup with a different name pattern). If so, SC needs the path or name of the actual "fix that worked."
3. **Reading C — the `/tmp` source was on AR's local machine, not on svr01:** AR may have built the standalone JS locally and the upload path was implicit. If so, SC needs the file uploaded (e.g., via paste-into-this-chat or scp from a02 if AR can place it there).

## §5 — What SC can do once AR clarifies

| AR says | SC action |
|---|---|
| "Reading A — leave it alone" | Mark hold resolved. No mutation. APAR-003 reclassified. |
| "Reading B — fix is at <path>" | SSH to svr01, inspect that path, propose the standalone-JS split, BU-FIRST + execute, evidence bundle, queued HL receipt. |
| "Reading C — here is the JS body" | AR pastes JS into chat or files at a path on a02; SC scp's to svr01 `/home/datacert/public_html/assets/gemwallet-verify.js`, adds `<script src="...">` to verify.html, BU-FIRST + verify + evidence + queued receipt. |
| "Restore from `false-success` backup as-is" | SSH svr01, `cp verify.html.bak.false-success-20260516153444 verify.html`, evidence, queued receipt — but this restores the URL-param fake-success path. Confirm AR wants that. |

## §6 — What SC has NOT done

- No file touched on svr01.dataveri.ai
- No file extracted, copied, or assembled
- No script tag added or removed
- No deploy directory rsynced
- No nginx, DNS, SSL touched
- No HL receipt queued (no mutation = no receipt needed)

## §7 — Related context AR may need

- The earlier 2026-05-16 i18n fix on `index.html` shipped and is live (different file, different bug). See `/ops/queue/approval/2026-05-16_SC_DONE_DATACERT_I18N_FIX.md`. That fix was straightforward because the source change (`setLang(saved);` → wrap in DOMContentLoaded) was a 1-character semantic change.
- This verify.html situation is harder because the proposed source file (`/tmp/datacert-gemwallet-verify.js`) is absent, the live verify.html size is 82B smaller than its most-recent backup, AND the diff lines up exactly with an intentional-looking "remove false success" path.
- APAR-003 has not yet shown up under `/ops/wo/apar/` on a02. AR said "Filing an APAR for the regression now" — the APAR file itself may still be in flight.

## §8 — Standing Rules Compliance

- ✅ Hostname/IP confirmed before any operation: `svr01.dataveri.ai` (161.35.103.13), Michelle's server, NOT AR's no-touch svr01.verity.one
- ✅ PTF-160 nginx untouched
- ✅ PTF-124 no credentials surfaced
- ✅ PTF-176 BU-FIRST would have been honored if a mutation had been attempted; investigation only used read-only ssh+grep+diff
- ✅ AGE §6 — Check-In trail covered by the broader DataCert task list; SC will write a dedicated Check-In for the mutation phase ONCE AR clarifies
- ✅ No fabrication — every claim above is backed by a verbatim ls / grep / diff / sha256 output

## §9 — Files Written This Turn

```
/ops/queue/approval/2026-05-16_SC_HOLD_DATACERT_VERIFY_HTML_APAR-003_AMBIGUOUS.md   ← this report
```

No other files. No mutation on svr01.dataveri.ai or a02.

## §10 — Next Move / Needs From

- **AR (single question):** which reading (A / B / C / restore-false-success) applies? Provide either a path to the actual fix on svr01, the JS body inline in chat, or a "leave it alone" if Reading A is right.
- **CC:** if APAR-003 ends up cancelled under Reading A, please flag SC so the kick to all reviewers from earlier today doesn't carry forward the false context.

TRUTH MATTERS® · Made in USA Inc. (OTC: USDW)