generated from coulomb/repo-seed
Add INTENT.md/SCOPE.md, reconcile PRD scope, rename content fingerprint
- Add INTENT.md (purpose and inviolable principles) and SCOPE.md (current operational boundary), matching the binect-js house style. - Reconcile the PRD with the shipped document-lifecycle scope: add ordering/server-sync requirements (4.3a), split the proxy queue vs. tracking-log caps (4.6.3), and update the solution summary/closing. - Rename computeMD5 -> computeContentFingerprint to be honest: it is a fast sampled non-cryptographic fingerprint for dedup, not MD5. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -8,6 +8,22 @@ BinectChromePrd
|
||||
|
||||
---
|
||||
|
||||
> **Revision note — scope evolution (2026-06).**
|
||||
> This PRD originally specified a minimal *detect → send* tool. The shipped
|
||||
> implementation has grown into a **document-lifecycle** assistant: it not only
|
||||
> uploads PDFs but tracks each one through its Binect server-side states
|
||||
> (in-basket → ordered → in production → sent), reconciles local records against
|
||||
> what Binect actually holds, and lets the user order and manage documents from
|
||||
> the popup. Sections **4.3a (Document Lifecycle & Ordering)** and **4.6
|
||||
> (Local Tracking)** below have been reconciled with this reality. The growth is
|
||||
> in-scope **only** because it never violates the inviolable principles in
|
||||
> [`INTENT.md`](../INTENT.md) §4 — in particular, the lifecycle is represented by
|
||||
> *metadata proxies that never hold PDF content*, and every server action (upload,
|
||||
> order, delete) remains user-initiated. The companion [`SCOPE.md`](../SCOPE.md)
|
||||
> records exactly what is implemented today.
|
||||
|
||||
---
|
||||
|
||||
## 1. Product Overview
|
||||
|
||||
### 1.1 Purpose
|
||||
@@ -39,8 +55,10 @@ BinectChrome:
|
||||
* Detects PDF downloads (and supported in-browser PDF views)
|
||||
* Offers a **“Send PDF to Binect”** action
|
||||
* Securely transfers the PDF to Binect via its API
|
||||
* Requires explicit user intent
|
||||
* Stores no PDF content
|
||||
* Tracks each sent document through its Binect lifecycle (in-basket → ordered → in production → sent) and lets the user place the print/delivery **order** with explicit confirmation
|
||||
* Reconciles local records against the documents Binect actually holds (server sync)
|
||||
* Requires explicit user intent for every send, order, and delete
|
||||
* Stores no PDF content — only lightweight metadata proxies
|
||||
* Tracks transfers locally for transparency and support
|
||||
|
||||
---
|
||||
@@ -133,6 +151,54 @@ PDFs rendered via blob URLs or complex JavaScript viewers may not be detectable
|
||||
|
||||
---
|
||||
|
||||
### 4.3a Document Lifecycle & Ordering
|
||||
|
||||
*(Added in the 2026-06 reconciliation. Distinguishes "uploaded to Binect" from
|
||||
"actually sent as physical mail," which the original PRD conflated.)*
|
||||
|
||||
#### 4.3a.1 Document Proxies (MUST)
|
||||
|
||||
* Each detected/sent PDF is represented locally by a **proxy**: a metadata-only
|
||||
record (filename, size, source, content hash, Binect document ID, status). The
|
||||
proxy **never contains PDF content**.
|
||||
* Proxies are deduplicated by filename + content hash so the same document is not
|
||||
tracked twice.
|
||||
|
||||
#### 4.3a.2 Lifecycle States (MUST)
|
||||
|
||||
* A proxy carries a status mirroring the Binect server lifecycle:
|
||||
`pending` → `uploading` → `in_basket` (uploaded, shippable) → `ordering` →
|
||||
`in_production` → `sent`, plus the off-path states `failed` and `canceled`.
|
||||
* The popup groups documents by lifecycle stage and shows the current status,
|
||||
price (when known), and recipient where available.
|
||||
|
||||
#### 4.3a.3 Ordering / Dispatch (MUST)
|
||||
|
||||
* Uploading a PDF places it in the Binect **basket** (shippable) but does **not**
|
||||
send physical mail.
|
||||
* Physically sending requires a **separate, explicit user action** ("order") with
|
||||
clear confirmation, because dispatch costs money and is irreversible.
|
||||
|
||||
#### 4.3a.4 Erroneous Documents (SHOULD)
|
||||
|
||||
* If Binect reports a document as erroneous, the extension surfaces the error and
|
||||
offers to refresh its status (the server may resolve it) or delete it.
|
||||
|
||||
#### 4.3a.5 Status Refresh & Server Sync (SHOULD)
|
||||
|
||||
* The user can refresh a document's status on demand.
|
||||
* The extension can **sync from the server**: list the documents Binect actually
|
||||
holds and reconcile them with local proxies — adopting server-discovered
|
||||
documents, updating statuses, and clearing server fields for documents deleted
|
||||
upstream.
|
||||
|
||||
#### 4.3a.6 Server-Side Deletion (MUST for delete actions)
|
||||
|
||||
* Deleting a document from Binect requires explicit user action; on success the
|
||||
local proxy is archived rather than silently dropped.
|
||||
|
||||
---
|
||||
|
||||
### 4.4 Authentication & Credential Handling
|
||||
|
||||
#### 4.4.1 Authentication Method (MUST)
|
||||
@@ -198,8 +264,18 @@ Tracking data stored **locally only**:
|
||||
|
||||
#### 4.6.3 Retention (SHOULD)
|
||||
|
||||
* Cap number of entries (e.g. last 500 events)
|
||||
* Prevent unbounded growth
|
||||
* Cap number of entries to prevent unbounded growth.
|
||||
* **Two distinct stores exist** after the lifecycle reconciliation, each capped
|
||||
independently:
|
||||
|
||||
* **Document proxy queue** (active lifecycle records): live vs. archived views;
|
||||
archived proxies age out after ~30 days; capped at ~100 entries.
|
||||
* **Tracking log** ("Score", append-only transfer events for transparency/CSV
|
||||
export): capped at the last ~500 events.
|
||||
|
||||
*(The original PRD named a single "≤ 500 events" cap. The implementation
|
||||
splits short-lived lifecycle proxies from the long-lived transfer log; the
|
||||
numbers above reflect the shipped behavior and may be tuned.)*
|
||||
|
||||
---
|
||||
|
||||
@@ -304,8 +380,11 @@ Expected permissions include:
|
||||
|
||||
---
|
||||
|
||||
**BinectChrome** is intentionally modest in scope:
|
||||
a focused, trustworthy bridge between modern cloud software and physical mail — implemented where the user already works: the browser.
|
||||
|
||||
|
||||
xxx
|
||||
**BinectChrome** is intentionally focused in scope:
|
||||
a trustworthy bridge between modern cloud software and physical mail —
|
||||
implemented where the user already works: the browser. It has grown from a pure
|
||||
*detect → send* tool into one that also follows each document through its Binect
|
||||
lifecycle, but it has not crossed its founding boundaries: no stored documents,
|
||||
no backend, no automatic dispatch. Those boundaries are recorded as inviolable
|
||||
principles in [`INTENT.md`](../INTENT.md), and the concrete delivered surface in
|
||||
[`SCOPE.md`](../SCOPE.md).
|
||||
|
||||
Reference in New Issue
Block a user