christian/helmdocs-proposal-system
1
0
Fork 0
Code Issues 8 Pull Requests Actions Packages Projects Releases Wiki Activity

Where does the transmission system get built? #2

New Issue
Closed
opened 2026-08-02 03:05:51 +00:00 by christian · 1 comment
christian commented 2026-08-02 03:05:51 +00:00
Owner
Copy Link

Question

Greenfield, or inside the existing novelpad-desktop monorepo that already holds the bidder-side proposal engine?

Parent: #1

## Question Greenfield, or inside the existing `novelpad-desktop` monorepo that already holds the bidder-side proposal engine? --- Parent: #1
christian added the
wayfinder:ticket
wayfinder:grilling
 labels 2026-08-02 03:05:51 +00:00
christian commented 2026-08-02 03:05:57 +00:00
Author
Owner
Copy Link

Resolution

Greenfield, server-authoritative. A new deployable for the retailer side and the transmission network. HelmDocs integrates later across an API/MCP boundary.

Why. The existing monorepo is client-first by architecture: PGlite on every client with ElectricSQL sync, Yjs documents, an Electron desktop app. That design replicates data down to clients — precisely wrong for a system whose core promise is that a vendor's bid never reaches another vendor's machine. Fighting that grain would be a permanent tax.

What this costs. Auth, org model, and billing get rebuilt. The two sides stay separate products until deliberately joined.

What is still reusable. The prompts and the thinking in packages/ai/src/agents/ (intake-classifier, go-no-go, compliance-matrix-builder, section-drafter, negative-rfp-review) and packages/core/src/solicitation-extraction/. Proven against real federal solicitations (NSF 26-510). Lift the design, not the runtime.

## Resolution **Greenfield, server-authoritative.** A new deployable for the retailer side and the transmission network. HelmDocs integrates later across an API/MCP boundary. **Why.** The existing monorepo is client-first by architecture: PGlite on every client with ElectricSQL sync, Yjs documents, an Electron desktop app. That design replicates data down to clients — precisely wrong for a system whose core promise is that a vendor's bid never reaches another vendor's machine. Fighting that grain would be a permanent tax. **What this costs.** Auth, org model, and billing get rebuilt. The two sides stay separate products until deliberately joined. **What is still reusable.** The prompts and the thinking in `packages/ai/src/agents/` (intake-classifier, go-no-go, compliance-matrix-builder, section-drafter, negative-rfp-review) and `packages/core/src/solicitation-extraction/`. Proven against real federal solicitations (NSF 26-510). Lift the design, not the runtime.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
wayfinder:grilling
HITL: resolved by conversation
wayfinder:map
The shared map for a wayfinding effort
wayfinder:prototype
HITL: resolved by making something rough
wayfinder:research
AFK: resolved by a research subagent
wayfinder:task
Manual work that unblocks a decision
wayfinder:ticket
A wayfinder decision ticket
No Label
wayfinder:grilling
wayfinder:ticket
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
christian
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: christian/helmdocs-proposal-system#2
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?