# Xboard ReplyTower Widget Feedback and Upload Improvement Plan

Date: 2026-07-31  
Mode: planning only  
Plan confidence: **92/100**. Make the widget expose the exact smallest upload constraint and prove connector health before customers enter chat. This is an executive judgment score, separate from fingerprint priority.

Governing product rule: ReplyTower owns the product-wide decision, tenant-safety, privacy, and verification gates. A fingerprint may enter execution only with a privacy-safe receipt, one accountable owner, explicit acceptance evidence, and a stop condition; shipped code without a live limit-chain receipt remains `△`. VPNCheap is first-customer evidence, not the governance authority.

## Verdict

The plugin computes the minimum across known positive ReplyTower, configured panel Nginx, PHP upload, and PHP post values. It is not yet a sound effective-limit contract: the default `panel_nginx_max_mb=0` means unknown and currently removes panel Nginx from the minimum. A lower live proxy can therefore reject above the advertised value. The live panel chain was not authorized for this audit, and PHP 2M remains a plausible but unverified explanation.

```text
BEFORE  four hidden limits -> one unexplained rejection
AFTER   four measured limits -> one effective cap -> one exact recovery path
```

## Evidence and state

- **MEASURED:** ReplyTower's current effective backend cap is 10MB; production ingress is 12MB.
- **MEASURED:** this plugin calculates the minimum of all positive layer limits and reserves multipart overhead from `post_max_size`.
- **OBSERVED:** the current request reports a 2MB experience.
- **INFERRED:** PHP's documented default `upload_max_filesize=2M` is the leading source. Disconfirm by reading the live panel PHP/Nginx/plugin settings.

`△△△△△ ☐☐☐ | 0/5/3/0`

| State | Feedback IDs | Local meaning |
|---|---|---|
| `○` | none | No local fingerprint has a current real-surface acceptance receipt. |
| `△` | RT-05, RT-06, RT-08, RT-16, RT-17 | Route-ID hardening, send/history, image-only rendering, and persistent limit-error implementations have focused tests; current live connector, embedded-widget, real-panel, onboarding, or full limit-chain receipts remain missing. |
| `☐` | RT-07, RT-14, RT-SEED-01 | Full preflight, ticket attachment contract, and live limit reconciliation remain open. |

## Execution sequence

Order follows dependency and owner sequence, not numeric rank. Canonical fingerprint scores and program-value judgments are different decision ledgers and are not directly comparable.

### 1. Live constraint-chain receipt, program value: 88/100

**PROPOSED:** an admin diagnostic reports backend cap, panel-Nginx setting, PHP upload cap, adjusted PHP post cap, selected effective bytes, plugin version, and measurement timestamp. Zero or absent panel-Nginx configuration is reported as `unknown`, never omitted. The widget must not advertise a negotiated cap above an unknown layer until that layer is explicitly measured or configured. The receipt never exposes secrets or customer payloads.

### 2. Connector and widget onboarding preflight, program value: 91/100

**PROPOSED:** contribute a versioned capability endpoint and browser round-trip to ReplyTower's accountable preflight. Failure uses stable machine codes for TLS, HMAC, path, permission, version, session, send, history, and handoff.

### 3. Adaptive image normalization, program value: 74/100

**PROPOSED:** accept a high-resolution screenshot selection, resize to ReplyTower's vision target, encode to a supported format, and show original-to-optimized bytes before upload. Keep the original local unless policy explicitly allows storage.

### 4. Ticket attachment connector contract, program value: 89/100

**PROPOSED:** carry safe image metadata and signed retrieval through ticket creation, reply, event, and history routes. ReplyTower remains accountable for end-to-end ticket acceptance.

Rejected shortcut: set PHP and Nginx to a larger number without a receipt, **36/100**. It can hide the current symptom while preserving drift and memory-cost risk.

## Phases

### 0-30 days

- Obtain explicit read-only authority for the exact VPNCheap panel target, then record every live limit layer and deployed plugin version.
- Freeze capability/reason-code and ticket-image contracts with ReplyTower.
- Run current widget session, send, history, upload, and handoff browser smoke in staging.

### 31-60 days

- Implement the diagnostic receipt, normalization, progress/cancel/retry, and ticket contract in an isolated branch.
- Test limit-minus-one, limit, limit-plus-one, missing content length, post overflow, invalid MIME, animation, high pixel count, cross-user/cross-tenant grants, and PHP empty-files behavior.

### 61-90 days

- Canary one tenant and observe constraint mismatch, upload abandonment, normalized bytes, 413, retry success, and vision success.
- Promote only after a real panel plus ReplyTower round trip produces a linked verification receipt.

### Phase gates

- **0-30:** evidence coverage reaches 100%.
- **31-60:** every scheduled P1/P2 acceptance is complete or explicitly approved `X`.
- **61-90:** two canary windows close without regression.
- Stop immediately on any listed guardrail.
- Any P3 acceleration requires a ReplyTower product-owner exception recorded with evidence, owner, acceptance, and stop condition; it never displaces P0-P2.

## Guardrails

- Do not claim PHP 2M as root cause until the live panel is read.
- Do not weaken HMAC, widget session binding, idempotency, tenant isolation, or signed media URLs.
- Do not log raw media, user text, tokens, callback secrets, or full URLs.
- Do not advertise a higher limit than any measured layer accepts.
- Treat zero or missing panel-Nginx configuration as unknown, not unlimited; block a higher capability claim until reconciled.