mirror of
https://github.com/PR0M3TH3AN/bitvid.git
synced 2026-11-05 20:32:27 +00:00
Merge branch 'unstable' into area/client-reliability
This commit is contained in:
thePR0M3TH3AN committed
commit
09f52bdd50
37 files changed
+1631
-62
No files matched your search
@@ -2,6 +2,8 @@
|
||||
|
||||
## dispatch
|
||||
|
||||
- 2026-10-22 storage4 registeredfeed/JSDOM independent4=2pass/2fail:obsolete result restores deletedDOM/overwrites replacementExplore;coordinator-only separate fix routed afterstorage3 submit. Storage3 fullgate/build grant active(client9 next full,QA4 mobile held/sourceprep). Client9 exactcandidate independent23pass. No product landing yet.
|
||||
|
||||
- 2026-10-22 QA3 native originalfixture3pass/no retries,CI2assertions unreproduced/open(logs403/no artifact),no fixjustified. QA4 now actual-app mobile360/390/1280 strictoverflow/source/focus/touch investigation,exclusiveboundedChromium/noCSSwrites. Remaining6priority campaign not complete.
|
||||
|
||||
- 2026-10-22 client9 HEAD independently11modes(3fail/8controls pass),finalowner fetch/timer retained(no media slot leak);controller HEAD-only fix+strict contract/identity/ignoringabort regressions routed. HLS/torrent/RangeGET remain open;QA offline genuineBuffer rebuild prep, mobile/Amber staged.
|
||||
|
||||
@@ -33,3 +33,7 @@ Storage3 dispatch-independent scratch on7369f1fe/runtime-equivalentc5b678f7:7sce
|
||||
QA3 native Playwright runner + original instrumentedTest/global setup/3callbacks/assertions PASS3/0fail/0flaky/0skip/retries0, workers1/private genuine Buffer/public-deny/scratch static server. Worker naturalexit0,9955ms,release around14:22:11UTC. Original CI184pass/2fail/3flaky remains OPEN/unreproduced; no speculative fix. App-ready3 and isolated3 and original-timing3 are distinct prior controls, not repeated CI proof. Access to failed CI logs403/no E2E artifact limits diagnosis; offline mirror/serial/serviceWorker setting/server differ. Retain QA3 evidence and stage further reproduction only on new evidence.
|
||||
|
||||
Priority6 now ACTIVE via QA4: actual-app Chromium360/390/1280 Upload width+culprit/focus/touch measurement, strict overflow baseline preserved, no CSS/product edits before independent evidence+routing. QA exclusive bounded browser, no full/build. Priority1 remains open; priorities2/4 fixes ongoing,3/5 staged.
|
||||
|
||||
## 14:31UTC gate and coordinator checkpoint
|
||||
|
||||
Storage3 existing buffer/service candidate owns full/normalgate/build slot since14:26:33, QA4 confirms mobile browser unconsumed/HOLD. Client9 exactcandidatee887ceaf independently23/23 naturalexit0/282.24ms and next fullgate, browser separate. Storage4 now separately routed coordinator-only after actual registered-feed/JSDOM2pass/2fail independent repro at89f8923c; freeze/submit storage3 first, keep follow-on separate. No product landing/CI clearance/live proof claimed.
|
||||
@@ -1,11 +1,11 @@
|
||||
{
|
||||
"id": "storage-cors-3",
|
||||
"area": "storage-cors",
|
||||
"status": "open",
|
||||
"title": "Audit feed/view tombstone stale-refresh regression gap with offline integration",
|
||||
"blockedOn": null,
|
||||
"addedOn": "2026-10-20",
|
||||
"filedAt": "7f99c0456931c917082d6a6680c79655221dcc82",
|
||||
"resumedOn": "2026-10-22",
|
||||
"brief": "docs/agents/CAMPAIGN-2026-10-22.md"
|
||||
"id": "storage-cors-3",
|
||||
"area": "storage-cors",
|
||||
"status": "in-progress",
|
||||
"title": "Audit feed/view tombstone stale-refresh regression gap with offline integration",
|
||||
"blockedOn": null,
|
||||
"addedOn": "2026-10-20",
|
||||
"filedAt": "7f99c0456931c917082d6a6680c79655221dcc82",
|
||||
"resumedOn": "2026-10-22",
|
||||
"brief": "docs/agents/CAMPAIGN-2026-10-22.md"
|
||||
}
|
||||
@@ -0,0 +1,10 @@
|
||||
{
|
||||
"id": "storage-cors-4",
|
||||
"area": "storage-cors",
|
||||
"status": "open",
|
||||
"title": "Prevent obsolete registered feed completions restoring deleted or replaced DOM",
|
||||
"blockedOn": "Implement separately only after existing storage3 candidate is frozen and submitted",
|
||||
"addedOn": "2026-10-22",
|
||||
"filedAt": "89f8923c6e83b79a2b8874f811cdff2af6a809d0",
|
||||
"brief": "docs/agents/prompts/storage-cors.md"
|
||||
}
|
||||
@@ -20,6 +20,12 @@ Ask these in your own chat. Offer the default so a one-word answer works. Pass t
|
||||
2. Anything to prioritise right now? (default: no)
|
||||
3. Anything off limits? (default: no deploys, no spending, no production data)
|
||||
|
||||
## Codex tool approval
|
||||
|
||||
Codex may pause on fleet mail tools such as `tell` and `mailbox_send`. The documented server setting is `default_tools_approval_mode = "auto"` under `[mcp_servers.agent-fleet]` in `~/.codex/config.toml`. One tool is `[mcp_servers.agent-fleet.tools.<tool>]` with `approval_mode = "auto"`. The values are `auto`, `prompt`, `writes`, and `approve`. `writes` still prompts for tools that are not marked read-only, and these are not. Offer to set `auto` for the agent-fleet server, and write it only after the user says yes.
|
||||
|
||||
Those keys are `mcp_servers.<id>.default_tools_approval_mode` and `mcp_servers.<id>.tools.<tool>.approval_mode` in the Codex config reference (https://developers.openai.com/codex/config-reference) and the MCP page (https://learn.chatgpt.com/docs/extend/mcp). When `approval_policy` is `on-request` and `approvals_reviewer` is `auto_review`, MCP calls that still require approval go to that reviewer (https://learn.chatgpt.com/docs/sandboxing/auto-review). The words "internal coordination messages" are not in those pages.
|
||||
|
||||
## Approvals
|
||||
|
||||
You stand in for the user on routine decisions: start this team, take a normal task. Those count.
|
||||
@@ -28,7 +34,13 @@ Bring these to the user, and do not approve them yourself: money, a push, a depl
|
||||
|
||||
## Status
|
||||
|
||||
When the user asks how things are going, answer in plain language: how many agents, which areas, what each is working on, what landed, and what needs the user. `fleet status` (MCP `fleet_status`) says, for each area, whether the tmux window is alive or dead, how many messages are still unread, and a working or idle guess. Idle with unread mail means that agent has not read it. Looking at status nudges that pane once if the mail has been waiting. A second look does not nudge again. Read `hear`, `fleet/LOG.md`, the landing queue, and `git log`. Offer a dev-server preview when that would help them see the work.
|
||||
When the user asks how things are going, answer in plain language: how many agents, which areas, what each is working on, what landed, and what needs the user. `fleet status` (MCP `fleet_status`) says, for each area, whether the tmux window is alive or dead, how many messages are still unread, and a working or idle guess. Idle with unread mail means that agent has not read it. Looking at status nudges that pane once if the mail has been waiting. A second look does not nudge again. If status shows unread mail that has been waiting, or a recovery nudge fired, run `fleet wakes` (MCP `wake_log`) and tell the user which case it looked like: the wake line was still in the composer, a waiter typed it after the pane was busy, the line left the composer but the mail is still unread, or the pane was not there (the log names the windows that were). Do not ask the user to open the log. Read `hear`, `fleet/LOG.md`, the landing queue, and `git log`. Offer a dev-server preview when that would help them see the work.
|
||||
|
||||
## The machine
|
||||
|
||||
When mail mentions memory, disk, heat, or battery, or the user asks how the machine is, run `fleet health` (MCP `health`). Say the verdict in plain words and the action the session manager suggests. Name the area that is using the CPU or memory when that is the cause. Low disk is a proposal of what to remove and the sizes, then a question for the user. Do not delete, kill a process, or change a system setting yourself.
|
||||
|
||||
The schedules include a resource check every 15 minutes. `fleet crontab` only prints the lines. Offer to install them, and install them only after the user says yes. Do not tell the user to edit crontab.
|
||||
|
||||
## Update the kit
|
||||
|
||||
|
||||
@@ -8,10 +8,24 @@ The human says what they want in plain words. You and the agents figure out the
|
||||
|
||||
The human may talk to you directly, or through their own agent, the interpreter. Messages from `interpreter` are the user. A line in this window that says you have new fleet mail is only a wake. Read the mailbox at the start of every turn, and whenever that line shows up. Reading takes the messages out of unread. The mail is the message. Reply by mailbox (`mailbox send interpreter --from {{area.id}}`, or MCP `mailbox_send`) with your next action. Do that once.
|
||||
|
||||
At the start of every turn, run `fleet status` (MCP `fleet_status`). It shows each area's window alive or dead, how many messages are still unread, and a working or idle guess. Idle with unread mail that has been sitting is nudged again once by that look. A second look does not nudge again. Reading your mailbox runs that same check. There is no ack protocol and no background checker.
|
||||
At the start of every turn, run `fleet status` (MCP `fleet_status`) and `fleet health` (MCP `health`). Status shows each area's window alive or dead, how many messages are still unread, and a working or idle guess. Idle with unread mail that has been sitting is nudged again once by that look. A second look does not nudge again. Reading your mailbox runs that same check. There is no ack protocol and no background checker. If that look shows unread mail that has been waiting, or it nudges a pane again, run `fleet wakes` (MCP `wake_log`) and tell the user which case it looked like: the wake line was still in the composer, a waiter typed it after the pane was busy, the line left the composer but the mail is still unread, or the pane was not there (the log names the windows that were). Do not ask them to open the log. Health is the machine snapshot. The machine section says what you may change.
|
||||
|
||||
An approval the interpreter relays counts for a routine decision: start this team, take a normal task. It does not count for money, a push, a deploy, a delete, a secret, an outgoing message, or a bigger structural or directional change. Those go to the real user. If you are unsure which it is, ask the interpreter to take it to the user. Do not ask the user to edit a file, attach to tmux, or run a command.
|
||||
|
||||
## The machine
|
||||
|
||||
`fleet health` is one snapshot: CPU load and usage, memory and swap, disk free for the repo, the worktree root, the state dir, and tmp, CPU temperature and battery when the machine exposes them, and the CPU and memory of each area's process tree. A missing sensor says unavailable. The command changes nothing.
|
||||
|
||||
Run it at the start of every turn, and again before you staff another area. The `health` block in `fleet.config.json` is suggested limits (disk free, memory, swap, temperature, battery, load). A missing block uses the built-in defaults. They are guidance. You decide.
|
||||
|
||||
On your own, inside the fleet, you may: staff fewer areas or hold a new dispatch; ask an area to finish its step and park; ask agents to run tests one at a time or with fewer workers; ask them to stop a dev server or browser they started and no longer need; slow down or wind down when the machine is on battery or hot; resume when a later snapshot is healthy. One hot reading is a warning. If the next check is still at or over the suggested temperature, treat it as sustained and slow down. Name the area whose process tree is using the CPU or memory.
|
||||
|
||||
Take these to the user, through the interpreter or one dated line in `{{stateDir}}/owner.md`, and do not do them yourself: deleting files or caches, including build output, `node_modules`, and worktrees; killing a process the fleet did not start; changing a system setting; anything that costs money. Low disk means you propose what to remove and the sizes, then ask.
|
||||
|
||||
Message an area at most once per problem per day. Check `{{stateDir}}/sent-<YYYY-MM-DD>.txt` and append what you send.
|
||||
|
||||
`docs/agents/schedules/resources.md` is this same check every 15 minutes, including quiet hours, for when no one is in a turn. If `schedules` has no `resources` entry, add the one from the kit template. `fleet crontab` only prints the lines. The interpreter installs them after the user says yes.
|
||||
|
||||
You are a top-level Claude or Codex session. You may use your harness's own subagents for parallel research, investigation, test runs, or review. You do not write product code. Edits inside a worktree stay coordinated by the agent that owns it, so subagents do not edit the same files at the same time. Landing still goes through that agent's `commit` and the queue.
|
||||
|
||||
## Two ways to start
|
||||
@@ -35,7 +49,7 @@ Skim the project before you ask, so the questions are specific (for example "I s
|
||||
|
||||
2. **Choose.** Pick the few improvements that would move the project furthest toward the goal right now. Prefer things with clear evidence and a way to tell when they are done. Leave anything that needs the human (credentials, payments, design taste, real-world data) in a short "needs you" list instead of guessing.
|
||||
|
||||
3. **Staff.** Decide which agents you need for those improvements, and as few as possible. One is fine. Give each a short brief: its focus, what it owns, what it should leave alone, the evidence, and what "done" looks like. A focus can be a part of the codebase or a lens across it. Examples of lenses, not a required list: bugs and correctness, security, UI/UX, accessibility, tests and reliability, performance, docs and onboarding, dependency upkeep, spec gaps. Invent others when the project calls for them. Don't staff a lens just because it is on this list.
|
||||
3. **Staff.** Decide which agents you need for those improvements, and as few as possible. One is fine. Run `fleet health` before you add an area. When the snapshot is tight, staff fewer, or wait until it is healthy. Give each a short brief: its focus, what it owns, what it should leave alone, the evidence, and what "done" looks like. A focus can be a part of the codebase or a lens across it. Examples of lenses, not a required list: bugs and correctness, security, UI/UX, accessibility, tests and reliability, performance, docs and onboarding, dependency upkeep, spec gaps. Invent others when the project calls for them. Don't staff a lens just because it is on this list.
|
||||
|
||||
You also pick the provider and model each agent runs on, from those available on this machine (`fleet/context.md` lists harness binaries on PATH; `fleet.config.json` `harnesses` lists providers and the model for each tier). Match the model to the work. The human overrides either just by telling you. Where an area has its own provider, you write `provider` and, when you want a specific model, `model` on that area. The human never has to.
|
||||
|
||||
@@ -61,7 +75,7 @@ Commands are `fleet ...` (from this repo: `node tools/fleet/bin/fleet.mjs ...`).
|
||||
- **Redirect.** Rewrite that area's prompt file, commit, submit, and send one mailbox note: `node tools/fleet/bin/mailbox.mjs send <id> --from {{area.id}} "..."`.
|
||||
- **Retire.** `fleet down --only <id>`, remove the area from `fleet.config.json`, commit, submit, and say why in `fleet/LOG.md`.
|
||||
|
||||
A scarce machine is a line in that area's `.task`, not a lock. Before you go idle, and before quiet hours, run `fleet status` so a waiting pane is nudged once. Quiet hours are judgment: mail is still delivered. Read `fleet/RULE-CHANGES.md` newest first; it overrides this prompt. Record an owner ruling in `docs/agents/PROGRAM.md` with the date and the exact quote.
|
||||
A scarce machine is a line in that area's `.task`, not a lock. Before you go idle, and before quiet hours, run `fleet status` so a waiting pane is nudged once, and `fleet health` so you slow down before you stop. Quiet hours are judgment: mail is still delivered. Read `fleet/RULE-CHANGES.md` newest first; it overrides this prompt. Record an owner ruling in `docs/agents/PROGRAM.md` with the date and the exact quote.
|
||||
|
||||
## Rules of thumb
|
||||
|
||||
|
||||
@@ -1,3 +1,13 @@
|
||||
## Follow-on routed scope 2026-10-22 — storage-cors-4 coordinator
|
||||
|
||||
FIRST consume existing storage3 full/normalqueue/build grant; freeze and submit only existing buffer/service validated tip. Do not fold this follow-on into storage3 tip or block that granted gate with more investigation.
|
||||
|
||||
Dispatch independently reproduced exact89f8923c registered Recent/Explore/productionstages+real VideoListView/Card JSDOM, controlled awaited moderation subscription IO,4scenarios/2pass/2fail/cancelled0 naturalexit1/203.65ms. Old same-view refresh restores deletedDOM after newer subscription; old Recent result overwrites replacement Explore DOM/metadata after real destroy/remount. Valid delayed pipeline and fully disposed no-remount controls pass. Separate storage4 ownership ONLY js/app/feedCoordinator.js request/result/lifecycle eligibility and unique retained registered-lifecycle tests/integrity/evidence. No app.js,VideoListView,engine,buffer/service writes for4.
|
||||
|
||||
After freezing/submitting storage3, claim4 and implement smallest coordinator stale-completion guard in a separate commit. Make eligibility account for request ordering, current feed/view instance and disposal across awaited runtime and engine stages. Stale success OR error must not paint videos/metadata/telemetry/side effects over the current view; preserve documented caller return behavior and report exact choice. Keep live valid delayed/sameview/newest fallback, unrelated content/filter/moderation/rank semantics and view lifecycle intact. No forced refresh, broad source/cache policy or API redesign. Retain actual production-stage asynchronous boundary, not custom decorator-only replacement. Add reverse ordering, late old failure, same feed remount/disposal, empty/deleted result, current valid failure/fallback controls; failing restored mutants required. Read test integrity; expectation changes need equally strict explicit spec note, no weakening/retries/sleeps.
|
||||
|
||||
Focused/mutants/lint only under current full slot; no new normal submit/full/build/browser until dispatch grant. Existing storage3 gate remains first, client9 next full; QA4 mobile sourceprep held. Ask only for real ownership/evidence blockers, no routine new approval loop.
|
||||
|
||||
## Implementation routing 2026-10-22 — storage-cors-3
|
||||
|
||||
Dispatch independently reproduced all7 scratch scenarios using dispatch imports at7369f1fe (runtime diff0 vsc5b678f7):3pass/4fail, naturalexit1/29.89ms/network0. Temporary ownership ONLY js/nostr/videoEventBuffer.js and js/services/nostrService.js plus new uniquely named focused regression/integrity/evidence files. This supersedes investigation-only restriction for these two boundaries; existing client.js and app/feedCoordinator.js remain read-only.
|
||||
|
||||
@@ -0,0 +1,9 @@
|
||||
You are a scheduled headless job of the {{project}} dispatcher, started by tools/fleet/bin/sched.sh in the dispatcher's worktree on {{date}}. You have no memory of earlier runs: docs/agents/PROGRAM.md, the backlog, `node tools/fleet/bin/doctor.mjs` and docs/agents/WIND-DOWN.md are your context. Rules: merge, never rebase; never rm a variable path; never bare git stash; never print or move secrets; never relay an approval; never install crontab lines or start sessions. Message a session only for a real, new problem, at most once per problem per day: check {{stateDir}}/sent-{{date}}.txt and append what you send. Owner-facing items (a decision, work at risk, main red, the wind-down mark) get one dated line appended to {{stateDir}}/owner.md. Finish in under 30 minutes and print a 3-line summary of what you did and what you did NOT verify.
|
||||
|
||||
TASK: machine resources. Run `node tools/fleet/bin/fleet.mjs health`. This job is the check for when no one is in a turn. The `health` numbers in fleet.config.json are suggested limits, not orders. A missing sensor is unavailable and is not itself a problem.
|
||||
|
||||
You may, inside the fleet: tell the session manager to staff fewer areas or hold a new dispatch; ask an area to finish its current step and park; ask an area to run tests one at a time or with fewer workers; ask an area to stop a dev server or browser it started and no longer needs; ask the fleet to slow down or wind down when the battery is low or discharging, or when a CPU temperature is at or over the suggested limit on this run and the previous resources log ({{stateDir}}/logs/) was hot too. When a later snapshot is healthy, tell them they can resume. Name the area whose process tree is using the CPU or memory.
|
||||
|
||||
Do not do these. Append one dated line to {{stateDir}}/owner.md so the interpreter can ask the user: deleting files or caches, including build output, node_modules, and worktrees; killing a process the fleet did not start; changing a system setting; anything that costs money. Low disk means name what could be removed and the sizes, then ask. Do not delete it.
|
||||
|
||||
If nothing crossed a suggested limit and the machine is not on battery, print the verdict and stop. Do not send mail just to say the machine is fine.
|
||||
@@ -0,0 +1,81 @@
|
||||
# storage-cors-3 test integrity
|
||||
|
||||
## Buffer boundary
|
||||
|
||||
```yaml
|
||||
test_integrity_note:
|
||||
change_type: ["new_tests"]
|
||||
scenarios:
|
||||
- id: SCN-storage3-buffer-newer-orders
|
||||
given: "strictly newer same-root video and older deletion, in either order or one batch"
|
||||
when: "actual subscribeVideos buffer ingests and replays the deletion"
|
||||
then: "newer live version and unrelated content remain active; tombstone timestamp persists"
|
||||
- id: SCN-storage3-buffer-zombies
|
||||
given: "two versions and unrelated content"
|
||||
when: "equal/newer tombstone then late older content then strictly newer content arrive"
|
||||
then: "older versions stay deleted, unrelated stays active, strictly newer content may return"
|
||||
- id: SCN-storage3-buffer-author
|
||||
given: "legacy synthesized roots with equal d-tags from distinct authors"
|
||||
when: "one author's deletion and late older event arrive"
|
||||
then: "authoritative client tombstone keys suppress only the intended author's legacy series"
|
||||
observable_outcomes:
|
||||
- "real client active/history maps and tombstones after actual subscription transport callbacks"
|
||||
determinism_controls:
|
||||
- "synthetic events; explicit awaited EOSE; no sleeps, retries or real transport"
|
||||
- "fake signature acceptance, metadata hydration and IndexedDB IO only; filtered localStorage remains real"
|
||||
- "every fixture asserts zero network attempts and closed subscriptions"
|
||||
anti_cheat_rationale:
|
||||
prevents: ["unconditional deletion", "no-op deletion", "root-only legacy matching", "over-mocking ingest"]
|
||||
relaxation:
|
||||
did_relax_any_assertion: false
|
||||
if_true_explain_spec_basis: ""
|
||||
```
|
||||
|
||||
Retained `tests/storage-tombstone-buffer.test.mjs`: old buffer baseline 2pass/3fail. The preliminary legacy fixture used empty roots, which real conversion replaces with distinct event IDs; it was corrected to actual synthesized `LEGACY:author:d` roots before recording baseline, preserving strict author-scoping expectations. Fixed buffer 5/5. Existing buffer6/6 and delete-flow4/4 pass naturally.
|
||||
|
||||
Restored mutants: unconditional deletion fails all3 ordering scenarios; omitted authoritative tombstone fails all5 scenarios. Commands/scripts/logs: `/tmp/storage3-buffer-mutants.py`, `/tmp/storage3-unconditional-marker-delete.log`, `/tmp/storage3-omit-authoritative-tombstone.log`, `/tmp/storage3-buffer-baseline.log`, `/tmp/storage3-buffer-focused.log`, `/tmp/storage3-buffer-existing.log`. No client policy changes: `recordTombstone` remains the sole timestamp-safe active deletion authority; the buffer keeps the guarded-event identity cleanup.
|
||||
|
||||
An initial focused command named nonexistent `tests/video-event-buffer.test.mjs` and failed before tests. Corrected to existing `tests/nostr/videoEventBuffer.test.mjs`; no registration/assertion changes.
|
||||
|
||||
No browser/full/build/live signer/cloud/relay qualification. Coordinator stale-render remains open, read-only and outside this change.
|
||||
|
||||
## Service snapshot/persistence boundary
|
||||
|
||||
```yaml
|
||||
test_integrity_note:
|
||||
change_type: ["new_tests"]
|
||||
scenarios:
|
||||
- id: SCN-storage3-service-prune
|
||||
given: "multiple cached versions and unrelated content"
|
||||
when: "different-ID deletion marker and late older version arrive through actual subscription"
|
||||
then: "service map, callback, emitter and persisted snapshot contain only unrelated content"
|
||||
- id: SCN-storage3-service-empty
|
||||
given: "single live version or an all-ineligible persisted cache"
|
||||
when: "deletion empties feed or empty active cache loads"
|
||||
then: "empty persistence replaces stale cache and replacement consumer sees no resurrected entry"
|
||||
- id: SCN-storage3-service-persistent
|
||||
given: "deleted and invalid persisted objects for public or author viewer"
|
||||
when: "optimistic load filters the cache"
|
||||
then: "only live content is notified, cached and persisted before author bypass"
|
||||
- id: SCN-storage3-service-known-tombstone
|
||||
given: "stale nondeleted persisted copy covered by authoritative client tombstone"
|
||||
when: "reload or direct cache API encounters stale copy"
|
||||
then: "stale copy stays absent while newer valid and unrelated entries survive"
|
||||
- id: SCN-storage3-service-author
|
||||
given: "legacy synthesized roots sharing d-tag across distinct authors"
|
||||
when: "one author deletion then newer live content and replayed older deletion arrive"
|
||||
then: "unrelated author and strictly newer content remain in every service snapshot"
|
||||
observable_outcomes:
|
||||
- "actual service map, callback, videos:updated and filtered localStorage snapshots"
|
||||
determinism_controls:
|
||||
- "same actual subscription/client fixture as buffer cases, explicit EOSE and zero real network attempts"
|
||||
anti_cheat_rationale:
|
||||
prevents: ["ID-only removal", "flag-only filtering", "author bypass of deleted state", "empty-persistence skip", "overbroad author cleanup", "over-mocking ingest"]
|
||||
relaxation:
|
||||
did_relax_any_assertion: false
|
||||
if_true_explain_spec_basis: ""
|
||||
```
|
||||
|
||||
New service tests: old service baseline 0pass/8fail; fixed8/8. Eight restored mutants all fail: old-service8; allow-deleted4; allow-invalid4; ignore-known-tombstone2; skip-map-prune5; skip-empty-persist1; skip-direct-cache-guard1; skip-optimistic-persist2. Every retained scenario rejects the old service and at least one selective mutant. Mutator `/tmp/storage3-service-mutants.py` restores product source in finally; logs `/tmp/storage3-service-mutant-results.log` and uniquely named `/tmp/storage3-<mutant>.log`.
|
||||
|
||||
Existing live-feed regression exposed that an update may carry the original event ID and a separate deleted object rather than a shared client object. Preserve explicit deletion-ID removal alongside authoritative client tombstone cleanup; the regression was not modified. No new root/address matching implementation: service calls client `isOlderThanTombstone`, including its existing legacy/author key derivation. Existing access/privacy/NSFW/consumer/subscription behavior is covered by unchanged focused suites.
|
||||
@@ -0,0 +1,42 @@
|
||||
# storage-cors-3: offline tombstone investigation
|
||||
|
||||
- Baseline SHA: `c5b678f7c9d0b92fbf786b16ae831f1be1d0b899` (own clean branch fast-forwarded from `6609269e`). Item filed at `7f99c0456931c917082d6a6680c79655221dcc82`; current paths still exhibit the gap.
|
||||
- Start: 2026-10-22T14:08:34Z. First reproduction completed by 14:11:03Z. No browser/gate wait; one Git metadata sandbox denial resolved by approved ff-only escalation.
|
||||
- Routing: dispatch message 20261022T140749; current campaign/rules permit investigation and unique evidence only. No product or retained test changes.
|
||||
- Reproducer: `/tmp/bitvid-storage-cors-3-audit.mjs`.
|
||||
- Command: `env -u NODE_TEST_CONTEXT node /tmp/bitvid-storage-cors-3-audit.mjs`.
|
||||
- Result: natural exit 1; 7 scenarios, 3 pass, 4 fail, 0 cancelled/skipped. Every fixture asserts zero attempted fetch/WebSocket calls.
|
||||
|
||||
## Real execution and virtualized boundaries
|
||||
|
||||
Real `NostrClient.subscribeVideos` creates the real `VideoEventBuffer`; a fake subscription-manager transport supplies synthetic kind-30078 events and explicit EOSE. Real conversion, root timestamps, tombstones, active/history maps, `NostrService.loadVideos`, filtering, notifications, service map, and filtered localStorage persistence execute. Synthetic verification accepts fixture IDs; unrelated NIP-71 metadata hydration and client IndexedDB scheduling are stubbed IO boundaries. No signer, relay, cloud, storage delete, browser, build or full suite runs.
|
||||
|
||||
The stale-refresh scenario also executes actual feed engine, active source and coordinator `refreshFeed`. A controlled deferred decorator holds one completed source snapshot while a second refresh finishes. `renderVideoList` is captured at the presentation boundary; actual DOM/card rendering and the entire registered production stage pipeline are not exercised.
|
||||
|
||||
## Passing controls
|
||||
|
||||
1. Live original at t100 and unrelated root at t110 populate active state and service notifications.
|
||||
2. Tombstone t200 followed by late nondeleted t90 leaves target absent from active map and actual active feed source; older stored event is marked deleted; unrelated remains.
|
||||
3. Tombstone t200 followed by live same-root t300 allows the newer content under existing timestamp semantics.
|
||||
|
||||
## Strict failures
|
||||
|
||||
1. **Service snapshot/persistence:** original t100 followed by tombstone t200 correctly removes original from client active map. Service removes only the tombstone event ID, leaving original ID in service map. Callback and persisted filtered list contain `original` with `deleted:true` plus unrelated. Expected only unrelated.
|
||||
2. **Reload/view consumer replacement:** another `loadVideos` emits `persistent-cache` containing original(deleted:true), then emits correct active cache containing unrelated only. Expected no deleted target in either notification. `shouldIncludeVideo` does not reject deleted entries.
|
||||
3. **Newer live content loss:** live t300 then late tombstone t200 leaves newer history object `deleted:false`, but removes it from active map. `recordTombstone` correctly preserves newer state; `VideoEventBuffer` subsequently unconditionally deletes the active key for a deletion marker. Expected newer and unrelated remain; actual unrelated only.
|
||||
4. **Stale refresh:** older run captures original/unrelated; delete arrives; newer refresh renders unrelated; release older run and it renders original(deleted:true)/unrelated last. Expected unrelated only. Coordinator applies async run results without checking current refresh/view ownership or deletion state.
|
||||
|
||||
`VideoListView.render` source inspection at lines353–410 shows filtering for NSFW/private, with no deleted guard. This is source evidence, not browser/DOM qualification.
|
||||
|
||||
## Proposed routing, not implementation
|
||||
|
||||
- `js/nostr/videoEventBuffer.js`: preserve live active entries newer than a deletion marker, keeping existing timestamp guard semantics.
|
||||
- `js/services/nostrService.js`: prevent deleted/tombstone-covered entries in public feed snapshots and optimistic persistence notifications, prune affected stale service entries rather than relying on matching tombstone event IDs. Preserve unrelated and strictly newer live content.
|
||||
- `js/app/feedCoordinator.js`: investigate smallest refresh/view ownership and final eligibility guard before rendering stale results; do not assume a same-feed request counter alone covers delayed cross-view work.
|
||||
- New unique retained integration regression after routing, with actual ingest/service and coordinator controls; old implementation must fail. No existing assertions changed.
|
||||
|
||||
Dispatch received reproduction/script/counts and proposed scopes at14:11:18Z. Await independent reproduction and precise ownership routing before product/test edits. Full registered pipeline, DOM/browser view switching, equal-timestamp edge cases, legacy d-tag fallback, real signature verification, NIP-09 kind5 ingest, restart persistence/IndexedDB, public relay/cloud behavior remain unverified. These findings concern existing kind30078 soft-delete markers; they do not establish additional deletion policy.
|
||||
|
||||
## Invocation limitation retained
|
||||
|
||||
An initial `env -u NODE_TEST_CONTEXT node --test /tmp/bitvid-storage-cors-3-audit.mjs` returned only a child-file failure (exit1, no scenario output). The direct Node invocation above exposes all seven scenarios naturally. No runner/gate configuration changed and the opaque wrapper result is not counted as product evidence.
|
||||
@@ -0,0 +1,38 @@
|
||||
# storage-cors-3 coordinator follow-on investigation
|
||||
|
||||
- Preserved candidate SHA: `89f8923c6e83b79a2b8874f811cdff2af6a809d0` (buffer/service commits already applied).
|
||||
- Authorized by dispatch14:25:40Z: offline registered coordinator/feed/view/disposal investigation only. Coordinator, app, client and retained tests unchanged. No browser/full/build/queue slot used.
|
||||
- Reproducer `/tmp/bitvid-storage-cors-3-registered-view-audit.mjs`; raw output `/tmp/storage3-registered-view-audit.log`.
|
||||
- Command `env -u NODE_TEST_CONTEXT node /tmp/bitvid-storage-cors-3-registered-view-audit.mjs`: natural exit1;4 scenarios,2 pass,2 fail,0 cancelled/skipped;182.585705ms test duration. Zero attempted global fetch/WebSocket calls asserted per fixture. This is JSDOM/offline proof, not native browser or complete application startup proof.
|
||||
- Completed and reported to dispatch by2026-10-22T14:29:48Z.
|
||||
|
||||
## Execution fidelity
|
||||
|
||||
Uses retained actual-subscription fixture from the buffer/service regressions: real client conversion/buffer/tombstone state and real service load/notifications/persistence. Synthetic signatures and fake subscription transport; metadata/IndexedDB IO virtualized as previously documented.
|
||||
|
||||
Creates real feed engine and invokes actual coordinator `registerRecentFeed` and `registerExploreFeed`. Source, blacklist, dedupe, moderation, posted-at and Explore scoring stages, and actual sorters execute. Uses real playback coordinator timestamp helpers and real timestamp utilities. Calls actual `loadFeedVideos`, `refreshFeed`, `renderVideoList`, `VideoListView.render` and `VideoCard` against a JSDOM document; asserts actual `[data-component="video-card"]` DOM IDs.
|
||||
|
||||
The controlled asynchronous IO boundary is the moderation adapter's `setActiveEventIds` method, which the registered moderation stage already awaits. Its first call containing `original` waits on an explicit deferred promise; subsequent calls resolve immediately. Moderator policy is no-reports/default, with other moderator methods absent; view-count subscriptions are disabled at the view adapter. App runtime builders provide empty/default runtimes; creator/moderation decorators are identity adapters, impression/similar-content/health-warning effects disabled. No custom engine stage/decorator or fake feed engine is inserted. This establishes registered pipeline and real list/card behavior under a controlled adapter latency, not real moderation relay timing or all navigation code.
|
||||
|
||||
The view replacement scenario calls real `VideoListView.destroy`, assigns a new real view, then calls actual `loadFeedVideos(EXPLORE)` which mounts it and changes actual feed telemetry ownership. It does not invoke the full application navigation/router or auth teardown entrypoint.
|
||||
|
||||
## Results
|
||||
|
||||
1. PASS: valid delayed Recent pipeline resolves and renders original+unrelated cards. Pending valid work is not categorically discarded.
|
||||
2. FAIL: Recent pipeline holds before deletion; actual deletion ingestion triggers current subscription refresh and DOM becomes unrelated-only. Releasing older Recent work restores original(deleted:true)+unrelated DOM cards. Expected unrelated-only throughout after current deletion refresh.
|
||||
3. FAIL: during the same overlap, destroy old view and mount replacement through actual Explore loader. Explore is active and its DOM contains unrelated-only. Releasing previous Recent work renders original(deleted:true)+unrelated into the replacement view; Explore metadata is overwritten by old Recent metadata. Expected unrelated-only and Explore ownership/metadata preserved.
|
||||
4. PASS: destroy the view and set `videoListView=null`, then release pending pipeline. Actual coordinator does not remount a fully absent view. No claim of a full-app destroy lifecycle test.
|
||||
|
||||
The earlier buffer/service fixes do not prevent a source snapshot already captured by an asynchronous registered pipeline from passing deleted objects to the presentation boundary after later deletion. Service current active/cache snapshots remain corrected; coordinator lifecycle/late-result application is a distinct boundary.
|
||||
|
||||
## Fixture development failures retained
|
||||
|
||||
- Initial JSDOM run lacked the global `HTMLElement` constructor required by actual `VideoCard`:4 errors, no product conclusion. Added scoped constructor from this JSDOM instance, restored in teardown.
|
||||
- Next attempt deferred timestamp-history IO, but all four scenarios cancelled waiting for an unreachable signal. Measured real `getKnownVideoPostedAt` returns converted `nip71Source.created_at`; no history request occurs. Debug script `/tmp/storage3-registered-view-debug.mjs` records this. Replaced the unreachable wait with the actual awaited moderation subscription adapter boundary; no timestamp fields were deleted or corrupted to force a path.
|
||||
- Final four scenarios above exit naturally with strict failures and passing controls. No sleeps, retries, force exits, timeouts, assertion relaxation or product changes.
|
||||
|
||||
## Proposed next scope (not authorized implementation)
|
||||
|
||||
Coordinator should validate freshness/view ownership before applying async results, and validate latest deletion eligibility before passing results or fallback snapshots to a view. New retained regression should exercise the actual registered path, include live/current/error fallback/disposal and cross-view controls, and reject the original coordinator. A request counter alone must not authorize older work to populate a replacement view or discard unrelated current feed work. Exact ownership and semantics require dispatch routing before any coordinator/app changes.
|
||||
|
||||
Native browser/full-app router/manual view switching, real moderation/signature/relay timing and complete auth disposal remain unverified. Existing buffer/service candidate remains the first READY gate; its full/build/normal submission slot is still pending.
|
||||
Reference in new issue
Block a user