Skip to content

id: document publish signs events but does not store blob bytes #1008

Open

Description

@dezren39

In pkgs/id, document publishing signs the document events but never stores the file/blob bytes, so there is no CLI path from a published document to its blob content.
Remains from the platform acceptance brief: wire publish to store the bytes (and confirm the blob gate, #173, applies to the stored path).
Source: review of session ses_ef03b7d73ffewFUtEk0FCMTiz5 (acceptance-brief gaps, seq 49269), Left-to-do item 3 in the 2026-10-26 two-week review FINAL.md.

Acceptance criteria

  • Publishing a document in pkgs/id stores its blob bytes through the same path other blob writes use, so a published document's content can be retrieved by its blob reference.
  • The blob gate tracked in Phase 3: blob gate is not wired into serve, so blobs are still served to any peer #173 applies to the stored-bytes path (publishing cannot bypass it).
  • A CLI or API path exists from a published document to its blob content, exercised end to end.
  • Existing publish/signing behavior is unchanged apart from the new storage step; relevant pkgs/id tests pass.

Activity

  1. developing-today commented on Oct 26, 2026

    @developing-today
    Contributor
  2. dezren39 commented on Oct 26, 2026

    @dezren39
    MemberAuthor

    Intake review

    Fleet monitor intake pass (2026-10-26): this issue arrived with no labels and no acceptance criteria; criteria appended to the body above, labels normalized.

    • Related: Phase 3: blob gate is not wired into serve, so blobs are still served to any peer #173 (the blob gate the stored-bytes path must respect — named in the body). Filed from the 2026-10-26 two-week review (acceptance-brief gaps, Left-to-do item 3).
    • Notes: The gap is a missing wire between two existing pieces — publish already signs events; blob storage already exists. The risk to check first is whether publish was deliberately kept bytes-free (e.g. a size or trust boundary); if so, that decision should be recorded on this issue rather than silently preserved.
    • Risks: Storing bytes on publish changes the publish cost profile for large documents; confirm the blob gate (Phase 3: blob gate is not wired into serve, so blobs are still served to any peer #173) semantics before wiring.
    • Suggested approach: Trace the publish path in pkgs/id, find where blob writes happen elsewhere, and connect publish to the same store call; add an end-to-end publish → retrieve test.
    • Labels: kind/bug, source/human, status/needs-triage, priority/normal, effort/m, app/id.
  3. added
    kind/bugSomething isn't working (prefixed form of the classic bug label)
    source/humanFiled directly by a human
    priority/normalOrdinary priority (the default)
    effort/mMedium: expected under 1 day of work
    app/idPackage/app: id (pkgs/ or apps/ in this repo)
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    and removed on Oct 26, 2026
  4. dezren39 commented on Nov 1, 2026

    @dezren39
    MemberAuthor

    agent-note:v1 — picked up (queue task 2302, Lane A, triage)

    Triaging against current main: locate the document publish path in pkgs/id, check whether it stores blob bytes, whether the #173 blob gate applies to that path, and whether any CLI/API path reaches a published document's blob content. Verdict + routing (scoped small_fix packet or close-with-evidence) to follow in this pass.

  5. 342 remaining items

  6. added
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    status/parkedDeliberately paused with a recorded resume condition
    queue/claimedQueue worker lifecycle state
    and removed
    queue/claimedQueue worker lifecycle state
    status/parkedDeliberately paused with a recorded resume condition
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    on Nov 4, 2026
  7. dezren39 commented on Nov 4, 2026

    @dezren39
    MemberAuthor

    agent-note:v1
    event: handed_off
    task: 4876 (repo-health-code-pilot; repo-worker-code; lane code-y)
    at: 2026-11-04T16:44Z
    found_via: atomic queue claim (lane code-y)
    verified: Issue #1008 OPEN, no hard-stop labels; claim labels resynced from parked to claimed. Dependency PR #3917 (author dezren39) still OPEN at fresh check — the resume gate for task 4876 remains unmet and that PR must not be touched. Execution-lane assignment for task 4876 is opencode — the bound opencode claimant session owns disposition; this lane does not work it directly. NOTE: attempts 24/24 (at cap) — if this claim's lease expires unbound, task 4876 risks terminal failure; a cap raise may be needed.
    next: Claimant launches the bound opencode session for task 4876; work resumes once PR #3917 merges.

  8. added
    queue/queuedHas a queued task in the Supabase agent queue
    and removed
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Nov 5, 2026
  9. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · handed off

    • Agent: fleet monitor
    • Session / ID: task 4876 (repo-fleet-monitor run 2026-11-05T15:32:18Z)
    • Found via: monitor reconciliation (Duty 1 claim/label divergence repair)
    • Task: Claim evaporated: task 4876 is queued and unclaimed in repo-health-code-pilot, but this issue still carried claimed labels. Labels reset to the truth (queue/queued + status/needs-triage). Checkpoint stage at evaporation: handed_off.
    • Expectation: The next lane claim picks task 4876 up from the queued state and posts a fresh pickup note.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

app/idPackage/app: id (pkgs/ or apps/ in this repo)effort/mMedium: expected under 1 day of workkind/bugSomething isn't working (prefixed form of the classic bug label)meta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedmode/onlineFully doable remotely: design, config, code, cloudpriority/normalOrdinary priority (the default)queue/queuedHas a queued task in the Supabase agent queuesource/humanFiled directly by a humanstatus/needs-triageNot yet triaged; needs a first looktask/triageQueue packet kind: verify, reproduce, and route this item

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions