# v-harness Upstream Manager

- Date: 2026-07-14
- Status: active internal upstream manager
- Goal: manage pinned upstream v-harness versions, protected live deployments,
  source lineage, and conservative internal adoption records.

This is an internal management subproject. It appears under Internal Iteration
so source lineage, deployment status and adoption claims remain visible and
reviewable, while the managed v-harness versions stay under External Projects.
It is not itself an algorithm experiment and never turns deployment evidence
into an adoption claim.

## Boundaries

The upstream source remains an independent Git repository/worktree. This
subproject owns only version metadata, deployment operations, public-safe
lineage, and internal reuse decisions. It does not fork or rewrite the mentor's
prompt, atomic operations, gate, epoch loop, or frontend.

## Managed Versions

| Version | Branch | Commit | Evidence / runtime |
| --- | --- | --- | --- |
| GLM v1 · v2.3.2 | `image2code-glm-v1` | `249c2bceedaf3c04f76ae3a899d91acbf8dc2641` | Protected FastAPI workbook on H100DEV1 |
| Native Claude · v2.3 | `image2code-v2.3` | `e9c04d4b382beaa18dc96f1e1fded91eb942dd76` | Verification Loop V3 static run evidence |
| Atomic Actions · v2.2 | `image2code-v2.2` | `e224610753529d5eae9a9589bd7485363f5ff1b6` | Verification Loop V2 and 13-case trajectory package |

Use these sources for different questions:

- `versions.json`: machine-readable navigation, pins, deployment and positive
  usage relationships.
- `SOURCE_LINEAGE.md`: source identity, archive integrity and drift policy.
- `VERSION_PROJECT_MATRIX.md`: which internal project executed, vendored,
  prepared, deployed or visualized each version.
- `ADOPTION_LEDGER.md`: whether an upstream mechanism is merely observed or has
  actually been adopted internally.

Stable version index:
`https://multimodal-verification-board.pages.dev/sp-vharness`.

Current protected GLM workbook:
`https://involve-fathers-proved-sensitive.trycloudflare.com/` (verified
2026-07-14 10:14 UTC; the shared board/VDiff access credential is required).

## Acceptance Canary

The completed GLM acceptance run is `case9/ed9c182d`, concurrency `1`, with
`MAX_EPOCHS=1`. It finished with a readable epoch timeline and the required
target, HTML, render, result and event artifacts. The deterministic gate
returned `FAIL` (`21` spatial issues and `3` visual issues); this is retained as
the model result and is not treated as a deployment failure. Production was
then restored to `MAX_EPOCHS=3`.

This canary establishes `deployment_only` evidence. It does not mean an internal
Verification Loop or VeriHarness experiment adopted the GLM source line.

## Runtime Shape

```text
browser
  -> password-protected Cloudflare Quick Tunnel
  -> deployment/app.py on 127.0.0.1:8200
  -> upstream web.server FastAPI app
  -> Claude Code CLI
  -> local anthropic_adapter.py on 127.0.0.1:8082
  -> GLM-5.2 OpenAI-compatible endpoint

upstream atomic perception
  -> local model proxy on 127.0.0.1:4151
  -> gemini-3.1-pro-preview
```

Runtime files live under ignored `.runtime/`; the shared access credential is
loaded from a local environment file and never enters the public board.

## Operations

From this subproject:

```bash
bash scripts/setup_runtime.sh
bash scripts/start_services.sh
bash scripts/start_tunnel.sh
bash scripts/smoke.sh
```

For the one-epoch acceptance run, start the services with `MAX_EPOCHS=1`, run
`bash scripts/run_canary.sh`, then restart normally so production returns to the
default `MAX_EPOCHS=3`.

To stop only this manager's processes:

```bash
bash scripts/stop_tunnel.sh
bash scripts/stop_services.sh
```

After a Quick Tunnel restart, update `versions.json` and the GLM board page with
the new URL, run the board sync script, and redeploy Cloudflare Pages.

The separate `20260714-vharness-frontend-study` subproject owns exhaustive UI
learning evidence. This manager links the study to its exact source pin but does
not duplicate its screenshots, interaction inventory or future design notes.

## Evidence Policy

- A canary gate failure is recorded honestly and is not a deployment failure.
- Missing artifacts, model connection errors, or an unreadable timeline are
  deployment failures.
- Runtime output is local/ignored and is never copied to Pages.
- No automatic root-repository commit is created while the existing worktree is
  dirty with unrelated changes.