Questions and decisions

Round 1

A1.

The primary v1 reader is one Hive operator reviewing all registered projects. Treat v1 as a private single-operator boundary: the same authenticated operator can see every registered project and its digest history. Team identities and per-project reader ACLs are outside v1.

Q2. What current habit or workaround should this replace, and what observable result after the first week would prove the digest is useful rather than merely another status screen?

A2.

Replace manually reconstructing the day from status output, task folders, PRs, CI, and logs. After the first week, success means the operator can quickly answer what advanced, completed, failed or recovered, remains blocked, and needs input across all projects, with direct action links and no manual cross-project reconciliation; the digest should surface at least one otherwise missed blocker or decision, or positively establish that no action is needed.

Q3. Which time zone owns day boundaries: one explicitly configured Hive-wide zone (recommended), the host machine's current local zone, or a per-reader zone? When the configured zone changes, should already-recorded days keep their original boundaries?

A3.

Use one explicitly configured Hive-wide IANA time zone. Default it from the host zone during setup, then persist the effective zone and day boundaries on each record. If configuration changes later, historical days retain their original boundaries.

Q4. When facts arrive after a day has closed—such as a delayed PR merge or a recovery observed the next morning—should Hive amend that historical day with an audit note, attribute the event only to the day it was observed, or keep closed days immutable and show the fact elsewhere?

A4.

Keep the original close immutable but allow append-only audited amendments. Record the event time when known, observed_at, source, and the amendment time; associate it with the effective historical day while making the late observation visible rather than silently rewriting the closed digest.

Q5. Should “materially advanced” use this baseline: include durable stage/state changes, completed work, new or changed PR/review/CI outcomes, answered decisions, and meaningful failures or recoveries; exclude repeated polling, log churn, and retries with no changed outcome? What should be added or removed?

A5.

Yes. Use that baseline. Also include task creation, archive or merge completion, and material provider, authority, or capacity holds only when their durable state changes. Continue excluding polls, repeated diagnostics, log churn, and retries that produce no changed outcome.

Q6. For work in progress, should a daily record show only tasks touched that day, all tasks still active at the day boundary, or touched tasks plus every currently blocked/unanswered task? For unanswered tasks, may it show task identity, project, stage, and waiting age while always omitting the question text?

A6.

Show tasks touched that day plus every task that is currently blocked or has unanswered operator input at the day boundary. For unanswered work, include project, task identity, stage or state, and waiting age, omit the question text, and link to the native answer flow.

Q7. How should `hive digest` behave by default: print today's concise digest in the terminal (with date/project/JSON/open-Web options), open today's Hive Web page, or choose another behavior? Sending Telegram should remain explicit or scheduler-owned rather than be an accidental side effect—agree or specify otherwise.

A7.

By default, print today's concise digest in the terminal. Support explicit date, project, JSON, and open-Web options. Agree that Telegram must be opt-in through an explicit command or scheduler and must never be a side effect of reading the digest.

Q8. Must the Hive-owned digest remain complete and readable when PRDigest or GitHub is unavailable, with PRDigest used only for optional PR enrichment/prose? Which PR details are essential in the durable record versus optional enrichment?

A8.

Yes. The Hive-owned digest must remain complete and readable without PRDigest and when GitHub is temporarily unavailable. Durable PR facts are project and task identity, PR number and URL, state or draft state, head revision, checks, review and merge outcome, and relevant timestamps when known. PRDigest may add optional prose or enrichment but is never authoritative.

Q9. What retention policy should v1 use for compact daily records: indefinite until manually pruned, a configurable duration with a default (name it), or a fixed duration? Should pruning remove only the digest projection while leaving normal task/PR evidence under its existing lifecycle?

A9.

Retain compact daily records indefinitely until an explicit operator action or configured future policy prunes them; v1 should not silently age them out. Pruning removes only the digest projection and must leave underlying task, attempt, PR, and audit evidence under their existing lifecycle.

Q10. Should Telegram delivery be opt-in, and if enabled should it send at day close, the following morning as a recap, or at a configurable local hour? On an empty day, should Telegram stay silent while Hive Web still exposes an explicit empty daily record?

A10.

Yes. Telegram delivery is opt-in and, when enabled, runs at a configurable local hour in the digest time zone, defaulting to a following-morning recap at 09:00. On an empty day Telegram stays silent, while Hive Web and explicit CLI reads expose an empty daily record.

Q11. If one project or PR source cannot be read, should Hive persist and display a partial digest with a clearly named gap (recommended), retry without publishing until complete, or fail the entire day? What recovery must be visible once the source returns?

A11.

Persist and display a partial digest with each unavailable source, gap reason, and freshness clearly named. Retry that source later; when it returns, append an audited recovery or amendment that shows which gap was resolved. A single missing source must not suppress the rest of the day.

Q12. The exact Web layout is inherently visual. For the next round, should Hive compare rough wireframes for the global day view and task-answer handoff, or keep the UI decision in text with lower-fidelity layout choices?

A12.

Compare rough wireframes for both the global day view and the task-answer handoff before settling the Web layout. Keep the behavioral and data contract in text, but use the wireframes to choose hierarchy, density, and action placement.

Requirements

Actor: One authenticated Hive operator can review digest history across every registered project. Team identities and per-project reader permissions are outside v1.
Outcome: The operator can quickly determine what advanced, completed, failed, recovered, remains blocked, or needs input without reconstructing the day from task files, status output, PRs, CI, and logs.
Daily record: Hive owns one durable global record per day. Day boundaries use a configured Hive-wide IANA time zone, initially defaulted from the host; each record persists its effective zone and boundaries so later configuration changes do not alter history.
Closing and amendments: Closing a day makes its original record immutable. Late facts are append-only audited amendments carrying the event time when known, observation time, source, and amendment time; they remain associated with the effective historical day and visibly identify the late observation.
Included activity: Record task creation; durable stage or state changes; completed, archived, or merged work; answered decisions; changed PR, review, or CI outcomes; meaningful failures and recoveries; and provider, authority, or capacity holds only when their durable state changes. Exclude polling, repeated diagnostics, log churn, and retries with no changed outcome.
Work in progress: Include tasks touched during the day plus every task blocked or awaiting operator input at the day boundary. An unanswered item shows project, task identity, stage or state, and waiting age, never the question text, and links to the task's native answer flow.
Web experience: Hive Web is the complete reading surface: one selected-day global view with project filters and direct task links. Before settling the layout, compare rough wireframes for the day view and answer handoff, using them to choose hierarchy, density, and action placement while preserving this behavioral contract.
CLI experience: hive digest prints today's concise digest by default and supports explicit date, project, JSON, and open-Web options. Reading a digest never sends Telegram messages.
Telegram experience: Delivery is opt-in and scheduler- or command-owned. When enabled, it sends a concise digest and Web link at a configurable local time in the digest zone, defaulting to a 09:00 following-morning recap. It stays silent for an empty day and remains a narrow notification/control surface rather than a general agent.
PR boundary: Hive remains authoritative for the broader activity digest and must stay complete and readable without PRDigest or live GitHub access. Durable PR facts include project and task identity, PR number and URL, state or draft state, head revision, checks, review and merge outcomes, and known relevant timestamps. PRDigest may supply optional facts or prose enrichment but does not own the record.
Degraded sources: A source failure produces a usable partial digest that names the unavailable source, reason, and freshness gap. Hive retries that source and appends an audited recovery or amendment when the gap is resolved; one missing source never suppresses the remaining day.
Retention: Compact daily records are retained indefinitely in v1 until explicit operator pruning or a future configured policy. Pruning removes only the digest projection, leaving normal task, attempt, PR, and audit evidence under its existing lifecycle.
Acceptance example — normal day: Given activity in several projects, the global day view groups the day's material changes, exposes project filtering, preserves actionable links, and lets the operator establish whether anything needs attention.
Acceptance example — unanswered task: Given a task awaiting input, the digest identifies it and its waiting age without leaking the question; selecting it opens the normal answer flow.
Acceptance example — partial and recovered source: Given unavailable PR data, the day is still published with a named gap; when the source returns, the historical day gains a traceable amendment showing that the gap was resolved.
Acceptance example — historical stability: Given a later time-zone change or delayed event, existing boundaries do not move and the late fact appears as an audited amendment rather than a silent rewrite.
Acceptance example — empty day and side effects: Given no qualifying activity, Hive Web and explicit CLI reads show an empty daily record, scheduled Telegram sends nothing, and ordinary hive digest reads cause no delivery side effect.