stackchain/stackchain-dashboard
1
0
Fork 0
Code Issues 9 Pull Requests 1 Actions Packages Projects Releases 713 Wiki Activity

Human Gates inbox: one hash-bound review queue to zero #1415

New Issue
Closed
opened 2026-08-25 23:37:07 +00:00 by rockachopa · 14 comments
rockachopa commented 2026-08-25 23:37:07 +00:00
Member
Copy Link

Problem

Telegram human-gate messages are getting lost among normal conversation and repeated automated status updates. Alexander needs one mobile inbox that can be worked to zero.

Product outcome

Add a first-class Human Gates queue to Stackchain Dashboard. Producers submit hash-bound review requests once; updates coalesce there. Telegram/push becomes a terse count + deep link, never the review record itself.

Required behavior

  • Durable account-bound SQLite gate store with pending, released, held, and superseded states.
  • Idempotent intake keyed by source + project + candidate hash; duplicate notifications update one card instead of creating another.
  • A newer candidate for the same source/project supersedes the older pending candidate without erasing its audit trail.
  • Default mobile inbox shows pending only, oldest/highest-priority first, with a visible count and Review next.
  • Gate detail shows title, project, exact candidate hash, artifacts/links, unmet checks, independent score/provenance, and history.
  • One-tap Release and Hold actions. Hold requires a reason. Release records the exact hash and checklist evidence; unmet required checks require an explicit override reason rather than a silent approval.
  • Decision & next advances through a fixed queue snapshot until zero and then shows a clear inbox-zero receipt.
  • Every mutation is idempotent, revision-checked, no-store, authenticated, and produces a durable decision receipt.
  • Deep route: #/my-work/human-gates; no repository/title/body content in lock-screen notification payloads.
  • Telegram integration contract: at most one coalesced message such as 3 human gates waiting with the deep link; gate details remain in the inbox.

First producer

The private creative review workflow that currently emits PRIVATE REVIEW — NOT RELEASED and asks for RELEASE or HOLD should post/update this inbox instead.

Acceptance

  • Strict RED-GREEN TDD for store, API, queue model, mobile UI, idempotency, supersession, stale revision, and inbox-zero flow.
  • 390x844 browser proof of pending list → detail → hold/release & next → zero.
  • Offline/read-only behavior is explicit: cached gates may be read, but decisions require confirmed online identity.
  • Existing My Work, Reviews, Updates, Today, auth, and push suites remain green.
  • No merge or deployment without independent reproduction and hostile review of the exact head.
## Problem Telegram human-gate messages are getting lost among normal conversation and repeated automated status updates. Alexander needs one mobile inbox that can be worked to zero. ## Product outcome Add a first-class **Human Gates** queue to Stackchain Dashboard. Producers submit hash-bound review requests once; updates coalesce there. Telegram/push becomes a terse count + deep link, never the review record itself. ## Required behavior - Durable account-bound SQLite gate store with pending, released, held, and superseded states. - Idempotent intake keyed by source + project + candidate hash; duplicate notifications update one card instead of creating another. - A newer candidate for the same source/project supersedes the older pending candidate without erasing its audit trail. - Default mobile inbox shows pending only, oldest/highest-priority first, with a visible count and **Review next**. - Gate detail shows title, project, exact candidate hash, artifacts/links, unmet checks, independent score/provenance, and history. - One-tap **Release** and **Hold** actions. Hold requires a reason. Release records the exact hash and checklist evidence; unmet required checks require an explicit override reason rather than a silent approval. - **Decision & next** advances through a fixed queue snapshot until zero and then shows a clear inbox-zero receipt. - Every mutation is idempotent, revision-checked, no-store, authenticated, and produces a durable decision receipt. - Deep route: `#/my-work/human-gates`; no repository/title/body content in lock-screen notification payloads. - Telegram integration contract: at most one coalesced message such as `3 human gates waiting` with the deep link; gate details remain in the inbox. ## First producer The private creative review workflow that currently emits `PRIVATE REVIEW — NOT RELEASED` and asks for `RELEASE` or `HOLD` should post/update this inbox instead. ## Acceptance - Strict RED-GREEN TDD for store, API, queue model, mobile UI, idempotency, supersession, stale revision, and inbox-zero flow. - 390x844 browser proof of pending list → detail → hold/release & next → zero. - Offline/read-only behavior is explicit: cached gates may be read, but decisions require confirmed online identity. - Existing My Work, Reviews, Updates, Today, auth, and push suites remain green. - No merge or deployment without independent reproduction and hostile review of the exact head.
rockachopa commented 2026-08-25 23:39:50 +00:00
Author
Member
Copy Link

Implementation context / migration inventory:

  • Paused noisy direct-delivery jobs while this inbox is built:
    • 7679c6cfd7cc Daily Drop Human Gate Receipt — script directly called hermes send despite local cron delivery.
    • c90e6f034448 Sovereign Signal Private Human Gate — delivered into the origin thread every 15 minutes.
  • Existing Daily Drop gates to import/coalesce:
    • 2026-08-23 The Tenth Test, hash c7f85e5a…, technical pass, human/score gates open. Alexander later replied “Approved”; migrate as a release override receipt rather than leaving it pending.
    • 2026-08-24 The Packet Is Not the Workshop, hash c21cc5db…, pending.
    • 2026-08-25 The Margin Traveled Too, no candidate hash because technical verification failed; pending correction, not releasable.
  • Sovereign Signal HARD MONEY, HUMAN HANDS is already APPROVED and belongs in history, not pending.

Do not resume either Telegram producer until it writes the inbox and only a coalesced count/deep-link notifier remains.

Implementation context / migration inventory: - Paused noisy direct-delivery jobs while this inbox is built: - `7679c6cfd7cc` Daily Drop Human Gate Receipt — script directly called `hermes send` despite local cron delivery. - `c90e6f034448` Sovereign Signal Private Human Gate — delivered into the origin thread every 15 minutes. - Existing Daily Drop gates to import/coalesce: - 2026-08-23 `The Tenth Test`, hash `c7f85e5a…`, technical pass, human/score gates open. Alexander later replied “Approved”; migrate as a release override receipt rather than leaving it pending. - 2026-08-24 `The Packet Is Not the Workshop`, hash `c21cc5db…`, pending. - 2026-08-25 `The Margin Traveled Too`, no candidate hash because technical verification failed; pending correction, not releasable. - Sovereign Signal `HARD MONEY, HUMAN HANDS` is already APPROVED and belongs in history, not pending. Do not resume either Telegram producer until it writes the inbox and only a coalesced count/deep-link notifier remains.
rockachopa commented 2026-08-26 00:09:13 +00:00
Author
Member
Copy Link

Independent controller review — CHANGES REQUESTED

Exact candidate: 3076ffa8808e70c714286906df73fa9fe82eca02 (base 7960f14b5b4946a356bfd90b0a475d510ebfbca5). Nothing pushed, merged, or deployed.

Baseline independently reproduced so far: Human Gates targeted/relevant tests 100 passed; syntax and diff checks pass. One contract failure blocks shipment:

Decision retry identity is not durable

frontend/human-gates.js creates a fresh random idempotency key on every click. If the server commits a Release/Hold but the response is lost, the UI keeps the gate and a retry generates a different key. The server then returns 409 Gate revision is stale; the user cannot recover the already-created receipt through the workflow.

Reproduction:

  • /tmp/human_gate_retry_probe.js produced two different keys for identical retry payloads: same:false.
  • Store probe: first decision committed; same decision under a new key returned GateConflict: Gate revision is stale.

Required correction: persist one operation identity and exact payload per gate revision/decision until a confirmed receipt is received; replay it after timeout/reload. On stale revision after an uncertain send, reconcile authoritative gate state and recover the account-bound receipt rather than making the operator guess.

Also complete the issue's first-producer requirement before shipment: current code documents intake but does not migrate daily_drop_human_gate_notify.py / Sovereign producers, import current gates, or provide a service-authenticated producer path. Both direct Telegram gate jobs remain paused to stop inbox noise.

A second hostile review of this exact head is still running; further findings may follow.

## Independent controller review — CHANGES REQUESTED Exact candidate: `3076ffa8808e70c714286906df73fa9fe82eca02` (base `7960f14b5b4946a356bfd90b0a475d510ebfbca5`). Nothing pushed, merged, or deployed. Baseline independently reproduced so far: Human Gates targeted/relevant tests `100 passed`; syntax and diff checks pass. One contract failure blocks shipment: ### Decision retry identity is not durable `frontend/human-gates.js` creates a fresh random idempotency key on every click. If the server commits a Release/Hold but the response is lost, the UI keeps the gate and a retry generates a different key. The server then returns `409 Gate revision is stale`; the user cannot recover the already-created receipt through the workflow. Reproduction: - `/tmp/human_gate_retry_probe.js` produced two different keys for identical retry payloads: `same:false`. - Store probe: first decision committed; same decision under a new key returned `GateConflict: Gate revision is stale`. Required correction: persist one operation identity and exact payload per gate revision/decision until a confirmed receipt is received; replay it after timeout/reload. On stale revision after an uncertain send, reconcile authoritative gate state and recover the account-bound receipt rather than making the operator guess. Also complete the issue's first-producer requirement before shipment: current code documents intake but does not migrate `daily_drop_human_gate_notify.py` / Sovereign producers, import current gates, or provide a service-authenticated producer path. Both direct Telegram gate jobs remain paused to stop inbox noise. A second hostile review of this exact head is still running; further findings may follow.
timmy was assigned by rockachopa 2026-08-26 00:10:31 +00:00
rockachopa commented 2026-08-26 00:13:15 +00:00
Author
Member
Copy Link

Full hostile review — CHANGES REQUESTED

Exact candidate reviewed: 3076ffa8808e70c714286906df73fa9fe82eca02 against 7960f14b5b4946a356bfd90b0a475d510ebfbca5.

Independent baseline is green (100 focused tests; 2695 passed, 24 skipped full suite), but invariant probes found these release blockers:

  1. #/my-work/human-gates is rejected by work-route.js and erased.
  2. API reports the full pending count but returns at most 100 items; a 102-gate queue falsely ends review with two pending. Storage/history/idempotency/receipt growth is also unbounded.
  3. A stale revision wedges the in-page fixed snapshot; refresh does not reset/reconcile it.
  4. Ownership uses mutable login rather than stable authenticated principal_id, permitting loss on rename and possible transfer if a login is reused.
  5. Decision retries create a new idempotency key after an uncertain response, defeating receipt replay/recovery.
  6. source is self-asserted by the request body, allowing one authorized actor to impersonate another producer and supersede its pending candidate.
  7. Project validation accepts ../..; URL validation accepts malformed https:// and authority-confusion forms.
  8. Separate has_*_key() preflights create a TOCTOU status race where concurrent first requests can both report 201.
  9. Queue card clicks ignore the selected gate ID and call reviewNext() on the current item.

Areas that held: parameterized SQL and atomic writes, immutable same-hash facts, account-scoped lookups under the current key, server-side release/checklist/override enforcement, 64 KiB request boundary, no-store coverage, DOM escaping, offline decision refusal, and cache purge on sign-out.

A bounded correction worker is now addressing every finding with a failing behavioral test before each fix. Candidate remains unpushed, unmerged, and undeployed. The direct Telegram gate jobs remain paused.

## Full hostile review — CHANGES REQUESTED Exact candidate reviewed: `3076ffa8808e70c714286906df73fa9fe82eca02` against `7960f14b5b4946a356bfd90b0a475d510ebfbca5`. Independent baseline is green (`100` focused tests; `2695 passed, 24 skipped` full suite), but invariant probes found these release blockers: 1. `#/my-work/human-gates` is rejected by `work-route.js` and erased. 2. API reports the full pending count but returns at most 100 items; a 102-gate queue falsely ends review with two pending. Storage/history/idempotency/receipt growth is also unbounded. 3. A stale revision wedges the in-page fixed snapshot; refresh does not reset/reconcile it. 4. Ownership uses mutable login rather than stable authenticated `principal_id`, permitting loss on rename and possible transfer if a login is reused. 5. Decision retries create a new idempotency key after an uncertain response, defeating receipt replay/recovery. 6. `source` is self-asserted by the request body, allowing one authorized actor to impersonate another producer and supersede its pending candidate. 7. Project validation accepts `../..`; URL validation accepts malformed `https://` and authority-confusion forms. 8. Separate `has_*_key()` preflights create a TOCTOU status race where concurrent first requests can both report `201`. 9. Queue card clicks ignore the selected gate ID and call `reviewNext()` on the current item. Areas that held: parameterized SQL and atomic writes, immutable same-hash facts, account-scoped lookups under the current key, server-side release/checklist/override enforcement, 64 KiB request boundary, no-store coverage, DOM escaping, offline decision refusal, and cache purge on sign-out. A bounded correction worker is now addressing every finding with a failing behavioral test before each fix. Candidate remains unpushed, unmerged, and undeployed. The direct Telegram gate jobs remain paused.
rockachopa commented 2026-08-26 00:25:38 +00:00
Author
Member
Copy Link

UX clarification from Alexander

The Human Gates front end should be deliberately simple. Every pending card gets two primary actions:

  • Review — open exact hash, artifacts, checks, provenance, history, Hold, and any exceptional override path.
  • Approve — one click for a clean candidate whose required checks all pass.

One-click Approve remains hash/revision-bound and produces the normal durable receipt. The click itself records the review attestations; there should not be three extra checkbox clicks on the clean path.

A blocked/failing candidate must not be silently one-click released. Its card routes to Review, where an explicit override reason is still required. Disable repeated submits while a decision is in flight and preserve the same operation identity across uncertain retries.

Acceptance tests should cover clean one-click approval, blocked candidate requiring Review/override, selected-card routing, and the 390×844 mobile layout.

## UX clarification from Alexander The Human Gates front end should be deliberately simple. Every pending card gets two primary actions: - **Review** — open exact hash, artifacts, checks, provenance, history, Hold, and any exceptional override path. - **Approve** — one click for a clean candidate whose required checks all pass. One-click Approve remains hash/revision-bound and produces the normal durable receipt. The click itself records the review attestations; there should not be three extra checkbox clicks on the clean path. A blocked/failing candidate must not be silently one-click released. Its card routes to Review, where an explicit override reason is still required. Disable repeated submits while a decision is in flight and preserve the same operation identity across uncertain retries. Acceptance tests should cover clean one-click approval, blocked candidate requiring Review/override, selected-card routing, and the 390×844 mobile layout.
rockachopa commented 2026-08-26 00:44:41 +00:00
Author
Member
Copy Link

Independent review of correction candidate 6aace003 — CHANGES REQUESTED

The correction passes its submitted targeted suite, but three adversarial probes still block shipment:

  1. Offline cache crosses stable-principal ownership. frontend/human-gates.js:16 keys cached gate facts by mutable login. A different Gitea principal reusing the same login on that browser receives the former principal's cached exact hashes/details before live fetch, or indefinitely offline. /tmp/human_gate_cache_reuse_probe.js observed leaked:true. Use stable authenticated principal ID for cache identity and never adopt legacy login-key gate caches.

  2. Detail decision double-click skips a gate. Only quick-card Approve is coalesced. Two rapid decideAndNext() calls submit twice, decrement pending_count twice, and advance the fixed snapshot twice. /tmp/human_gate_detail_double_probe.js observed posts:2, current c, while b remained queued. Coalesce/disable every decision path by exact gate/revision/decision operation and apply a receipt once.

  3. Structurally malformed cursors reach SQLite. A base64/JSON-valid cursor containing a list/object in a numeric position raises sqlite3.ProgrammingError, which the API reports as temporary store failure (503). Validate exact cursor arity, scalar types/ranges, and ordering fields before SQL; invalid cursors must be 422.

The exact candidate remains unpushed, unmerged, and undeployed. A second independent hostile reviewer is still testing the head for additional findings.

## Independent review of correction candidate `6aace003` — CHANGES REQUESTED The correction passes its submitted targeted suite, but three adversarial probes still block shipment: 1. **Offline cache crosses stable-principal ownership.** `frontend/human-gates.js:16` keys cached gate facts by mutable login. A different Gitea principal reusing the same login on that browser receives the former principal's cached exact hashes/details before live fetch, or indefinitely offline. `/tmp/human_gate_cache_reuse_probe.js` observed `leaked:true`. Use stable authenticated principal ID for cache identity and never adopt legacy login-key gate caches. 2. **Detail decision double-click skips a gate.** Only quick-card Approve is coalesced. Two rapid `decideAndNext()` calls submit twice, decrement `pending_count` twice, and advance the fixed snapshot twice. `/tmp/human_gate_detail_double_probe.js` observed `posts:2`, current `c`, while `b` remained queued. Coalesce/disable every decision path by exact gate/revision/decision operation and apply a receipt once. 3. **Structurally malformed cursors reach SQLite.** A base64/JSON-valid cursor containing a list/object in a numeric position raises `sqlite3.ProgrammingError`, which the API reports as temporary store failure (503). Validate exact cursor arity, scalar types/ranges, and ordering fields before SQL; invalid cursors must be 422. The exact candidate remains unpushed, unmerged, and undeployed. A second independent hostile reviewer is still testing the head for additional findings.
rockachopa commented 2026-08-26 00:45:43 +00:00
Author
Member
Copy Link

390×844 visual receipt — additional blockers

I rendered the exact 6aace003 UI at 390×844 with real Chromium. Geometry showed no horizontal overflow and 44px action targets, but the screenshot found two visual blockers:

  • The Human Gates heading and Close control are hidden behind the persistent Stackchain top bar. Only a clipped pending-count line is visible below it, so the panel is not clearly identified and cannot be visibly closed.
  • The disabled Approve button on a blocked candidate is visually nearly identical to the enabled Approve button on a clean candidate. That creates a false one-click affordance instead of making “Review required” unmistakable.

The persistent bottom navigation also overlays the panel viewport. Correction needs explicit mobile chrome/layer spacing and a clearly disabled/omitted blocked Approve action, backed by a real 390×844 screenshot/geometry test.

## 390×844 visual receipt — additional blockers I rendered the exact `6aace003` UI at 390×844 with real Chromium. Geometry showed no horizontal overflow and 44px action targets, but the screenshot found two visual blockers: - The Human Gates heading and Close control are hidden behind the persistent Stackchain top bar. Only a clipped pending-count line is visible below it, so the panel is not clearly identified and cannot be visibly closed. - The disabled Approve button on a blocked candidate is visually nearly identical to the enabled Approve button on a clean candidate. That creates a false one-click affordance instead of making “Review required” unmistakable. The persistent bottom navigation also overlays the panel viewport. Correction needs explicit mobile chrome/layer spacing and a clearly disabled/omitted blocked Approve action, backed by a real 390×844 screenshot/geometry test.
rockachopa commented 2026-08-26 00:53:44 +00:00
Author
Member
Copy Link

Second hostile review complete — correction launched

The second independent reviewer confirmed the cache, cursor, double-decision, and 390×844 findings. It also found the HTTPS reference validator still accepts ambiguous inputs including fullwidth/confusable hosts, percent-encoded authority characters, trailing-dot hosts, empty/out-of-range/custom ports, fragments, and percent-encoded controls.

Examples accepted by 6aace003 included:

  • https://ｅxample.com/path
  • https://%65xample.com/path
  • https://evil%40trusted.example/path
  • https://example.com:99999/path
  • https://example.com/path#https://evil.test
  • https://example.com/%0aevil

A new bounded correction is fixing all five remaining blocker groups with failing tests first, including real Playwright geometry at 390×844. Exact candidate remains unpushed, unmerged, and undeployed.

## Second hostile review complete — correction launched The second independent reviewer confirmed the cache, cursor, double-decision, and 390×844 findings. It also found the HTTPS reference validator still accepts ambiguous inputs including fullwidth/confusable hosts, percent-encoded authority characters, trailing-dot hosts, empty/out-of-range/custom ports, fragments, and percent-encoded controls. Examples accepted by `6aace003` included: - `https://ｅxample.com/path` - `https://%65xample.com/path` - `https://evil%40trusted.example/path` - `https://example.com:99999/path` - `https://example.com/path#https://evil.test` - `https://example.com/%0aevil` A new bounded correction is fixing all five remaining blocker groups with failing tests first, including real Playwright geometry at 390×844. Exact candidate remains unpushed, unmerged, and undeployed.
rockachopa commented 2026-08-26 01:01:34 +00:00
Author
Member
Copy Link

Private lab frontend preview

Interactive synthetic-data preview is served at:

https://forge.alexanderwhitestone.com/timmy-staging/human-gates/

  • Uses the existing lab/staging Basic Auth boundary.
  • No DNS or domain-registry change.
  • Standalone static preview: Review, clean one-click Approve, blocked Review/override, receipts, and inbox zero.
  • No production API calls, service worker, cookies, localStorage, or real release side effects.
  • 390×844 Chromium check: no horizontal overflow; controls are visible and at least 44px tall.
  • Immutable preview release directory: f456a3b897a7.

This preview is a UX handoff only. The integrated backend candidate remains blocked from merge/deployment until exact-head hostile review passes.

## Private lab frontend preview Interactive synthetic-data preview is served at: `https://forge.alexanderwhitestone.com/timmy-staging/human-gates/` - Uses the existing lab/staging Basic Auth boundary. - No DNS or domain-registry change. - Standalone static preview: Review, clean one-click Approve, blocked Review/override, receipts, and inbox zero. - No production API calls, service worker, cookies, localStorage, or real release side effects. - 390×844 Chromium check: no horizontal overflow; controls are visible and at least 44px tall. - Immutable preview release directory: `f456a3b897a7`. This preview is a UX handoff only. The integrated backend candidate remains blocked from merge/deployment until exact-head hostile review passes.
rockachopa commented 2026-08-26 01:24:20 +00:00
Author
Member
Copy Link

Exact-head UX review of 48acc938 — one blocker remains

The security/race corrections pass the expanded targeted suite (174 passed independently), and the 390×844 geometry is no longer clipped. However, the exact screenshot and a deterministic probe show the integrated inbox still violates the requested simple interaction:

  • Opening Human Gates automatically calls reviewNext() and renders the first full detail below the cards before Alexander clicks Review.
  • This duplicates the first candidate and immediately adds mostly empty Artifacts, Links, Checks, Provenance, and History sections.
  • There is no Back/Close-detail control; the only visible Close exits the whole inbox.

Probe /tmp/human_gate_simple_ui_probe.js observed:

{"detailAutoOpened":true,"reviewButtons":1,"detailHasBack":false}

Required UX: initial route is card-only. Review intentionally opens one focused detail view/modal with a clear Back/Close-to-list action. Clean Approve remains one click from the card. After a reviewed decision, return to the card list or intentionally open the next review only when the operator chose a review-to-zero session.

Candidate remains unpushed, unmerged, and undeployed. The private lab preview already demonstrates the desired card-first behavior at /timmy-staging/human-gates/.

## Exact-head UX review of `48acc938` — one blocker remains The security/race corrections pass the expanded targeted suite (`174 passed` independently), and the 390×844 geometry is no longer clipped. However, the exact screenshot and a deterministic probe show the integrated inbox still violates the requested simple interaction: - Opening Human Gates automatically calls `reviewNext()` and renders the first full detail below the cards before Alexander clicks **Review**. - This duplicates the first candidate and immediately adds mostly empty Artifacts, Links, Checks, Provenance, and History sections. - There is no Back/Close-detail control; the only visible Close exits the whole inbox. Probe `/tmp/human_gate_simple_ui_probe.js` observed: ```json {"detailAutoOpened":true,"reviewButtons":1,"detailHasBack":false} ``` Required UX: initial route is card-only. **Review** intentionally opens one focused detail view/modal with a clear Back/Close-to-list action. Clean **Approve** remains one click from the card. After a reviewed decision, return to the card list or intentionally open the next review only when the operator chose a review-to-zero session. Candidate remains unpushed, unmerged, and undeployed. The private lab preview already demonstrates the desired card-first behavior at `/timmy-staging/human-gates/`.
rockachopa commented 2026-08-26 01:33:53 +00:00
Author
Member
Copy Link

Final hostile review of 48acc938 — two corrections required

The reviewer independently confirmed the card-first UX defect and found one additional queue correctness race:

  1. Opening the inbox auto-renders the first detail and offers no Back-to-list control. Correct behavior is cards only until Review is clicked.
  2. A delayed pre-decision load() response can arrive after a successful decision-to-zero and resurrect the decided gate in the queue/cache. Loads need coalescing or mutation-generation guards so stale reads cannot overwrite newer decisions.

All prior security, principal isolation, cursor, URL, decision-idempotency, no-store/auth/CSRF, DOM/XSS, and mobile geometry probes held.

A final bounded TDD correction is running for these two findings. The private lab preview remains available and already uses the desired card-first interaction. Integrated candidate remains unpushed, unmerged, and undeployed.

## Final hostile review of `48acc938` — two corrections required The reviewer independently confirmed the card-first UX defect and found one additional queue correctness race: 1. Opening the inbox auto-renders the first detail and offers no Back-to-list control. Correct behavior is cards only until **Review** is clicked. 2. A delayed pre-decision `load()` response can arrive after a successful decision-to-zero and resurrect the decided gate in the queue/cache. Loads need coalescing or mutation-generation guards so stale reads cannot overwrite newer decisions. All prior security, principal isolation, cursor, URL, decision-idempotency, no-store/auth/CSRF, DOM/XSS, and mobile geometry probes held. A final bounded TDD correction is running for these two findings. The private lab preview remains available and already uses the desired card-first interaction. Integrated candidate remains unpushed, unmerged, and undeployed.
rockachopa commented 2026-08-26 01:48:05 +00:00
Author
Member
Copy Link

Exact-head controller probe of b9352d3 — one interaction regression

The initial 390×844 card-first view now matches the requested simple UI, and the stale-load regression is covered. One-click Approve still accidentally enters review-session mode:

  • approve(gateId) calls select(gateId).
  • After the clean approval succeeds, performDecision() advances reviewIndex and calls reviewNext().
  • With another gate pending, the list disappears and the next full detail opens automatically.

Probe /tmp/human_gate_quick_approve_stays_list_probe.js after approving card A with card B pending:

{"listHidden":true,"detailHidden":false,"current":"b","detail":true,"queue":["b"]}

Required behavior: one-click card Approve removes the clean card and remains on the compact card list. Only an explicit Review click should enter/continue the review-to-zero detail session. Add a two-card regression and mobile interaction assertion.

Candidate remains unpushed, unmerged, and undeployed.

## Exact-head controller probe of `b9352d3` — one interaction regression The initial 390×844 card-first view now matches the requested simple UI, and the stale-load regression is covered. One-click Approve still accidentally enters review-session mode: - `approve(gateId)` calls `select(gateId)`. - After the clean approval succeeds, `performDecision()` advances `reviewIndex` and calls `reviewNext()`. - With another gate pending, the list disappears and the next full detail opens automatically. Probe `/tmp/human_gate_quick_approve_stays_list_probe.js` after approving card A with card B pending: ```json {"listHidden":true,"detailHidden":false,"current":"b","detail":true,"queue":["b"]} ``` Required behavior: one-click card Approve removes the clean card and remains on the compact card list. Only an explicit **Review** click should enter/continue the review-to-zero detail session. Add a two-card regression and mobile interaction assertion. Candidate remains unpushed, unmerged, and undeployed.
rockachopa commented 2026-08-26 02:12:38 +00:00
Author
Member
Copy Link

Exact-head 7ba1481 hostile verdict — CHANGES REQUESTED

The full suite passed (2774 passed, 24 skipped), but independent probes found two release blockers:

  1. If a decision POST returns 409 and the authoritative reconciliation GET then fails, cached data is incorrectly treated as authoritative: the client returns reconciled: true, deletes the persisted operation, and may show the stale conflicted card.
  2. In real Chromium at both 390×844 and 320×568, focused-detail buttons (Back to gates, Approve & next, Hold & next) measure 33px high rather than the required 44px mobile target.

A bounded strict-TDD correction is running. Candidate remains unpushed, unmerged, and undeployed.

## Exact-head `7ba1481` hostile verdict — CHANGES REQUESTED The full suite passed (`2774 passed, 24 skipped`), but independent probes found two release blockers: 1. If a decision POST returns `409` and the authoritative reconciliation GET then fails, cached data is incorrectly treated as authoritative: the client returns `reconciled: true`, deletes the persisted operation, and may show the stale conflicted card. 2. In real Chromium at both 390×844 and 320×568, focused-detail buttons (**Back to gates**, **Approve & next**, **Hold & next**) measure 33px high rather than the required 44px mobile target. A bounded strict-TDD correction is running. Candidate remains unpushed, unmerged, and undeployed.
timmy commented 2026-08-26 02:30:45 +00:00
Owner
Copy Link

Main advanced: neutral reconciliation in progress

Exact candidate 78a4977 passed hostile review and full verification (2776 passed, 24 skipped). Before push, origin/main was refreshed and found to already contain merged Human Gates PR #1416 at e9d257e, with a parallel implementation and progressive identity-hydration fixes.

A direct rebase exposed substantive overlapping design conflicts, so it was aborted cleanly rather than choosing a side blindly. A neutral reconciliation is now porting only the independently proven missing/superior invariants from 78a4977 onto current main while preserving #1416's disjoint fixes. The resulting exact head will be fully re-tested and hostile-reviewed before any push or PR.

No branch has been pushed from this work and nothing was merged or deployed by this controller.

## Main advanced: neutral reconciliation in progress Exact candidate `78a4977` passed hostile review and full verification (`2776 passed, 24 skipped`). Before push, `origin/main` was refreshed and found to already contain merged Human Gates PR #1416 at `e9d257e`, with a parallel implementation and progressive identity-hydration fixes. A direct rebase exposed substantive overlapping design conflicts, so it was aborted cleanly rather than choosing a side blindly. A neutral reconciliation is now porting only the independently proven missing/superior invariants from `78a4977` onto current main while preserving #1416's disjoint fixes. The resulting exact head will be fully re-tested and hostile-reviewed before any push or PR. No branch has been pushed from this work and nothing was merged or deployed by this controller.
timmy commented 2026-08-26 02:53:55 +00:00
Owner
Copy Link

Reconciled head e6fc86f — CHANGES REQUESTED

Current-main integration kept progressive behavior green (2778 passed, 24 skipped) but hostile review found four blockers:

  1. Migration quarantines current-main <principal_id>:<login> gates/receipts into an unreachable legacy namespace.
  2. If a decision commits but its response is lost, reload can remove the card before the persisted operation is replayed, orphaning receipt recovery.
  3. Quick and detail decisions use separate flights, allowing simultaneous Release and Hold POSTs for one gate/revision.
  4. URL admission accepts browser-rewritten numeric authorities and non-canonical :0443.

A strict-TDD correction is running on the current-main integration branch. Nothing has been pushed, merged, or deployed by this controller.

## Reconciled head `e6fc86f` — CHANGES REQUESTED Current-main integration kept progressive behavior green (`2778 passed, 24 skipped`) but hostile review found four blockers: 1. Migration quarantines current-main `<principal_id>:<login>` gates/receipts into an unreachable legacy namespace. 2. If a decision commits but its response is lost, reload can remove the card before the persisted operation is replayed, orphaning receipt recovery. 3. Quick and detail decisions use separate flights, allowing simultaneous Release and Hold POSTs for one gate/revision. 4. URL admission accepts browser-rewritten numeric authorities and non-canonical `:0443`. A strict-TDD correction is running on the current-main integration branch. Nothing has been pushed, merged, or deployed by this controller.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
P0

Drop everything

  
P1

High priority

  
P2

Medium priority

  
agent:nightprowl

Assignments routed to the LongCat NightProwl evaluation worker

  
backend

Backend service

  
ci

Continuous integration / actions

  
frontend

Frontend / UI

  
meta

Meta / planning

  
pages

Gitea Pages

  
template

Repo template / standards

No Label
P0
P1
P2
agent:nightprowl
backend
ci
frontend
meta
pages
template
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
timmy
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: stackchain/stackchain-dashboard#1415
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?