Choose the application architecture and deployment contract #11

New issue

Open

opened 2026-10-20 21:29:41 +00:00 by phg · 0 comments

phg commented

2026-10-20 21:29:41 +00:00

Owner

Part of #1

Question

Which stack and operating contract best implement the agreed specification for a self-hosted, single-hackerspace web application?

There are no existing backend, database, deployment, mail, or OAuth-provider constraints. Compare a small number of concrete options for application runtime, durable queue/assignment storage and concurrency, inbound/outbound mail, background processing, authentication, PWA push, and deployment. Cover idempotency and durable dispatch, configuration/secret ownership, backups and restore, monitoring of stalled distribution, and the event-adapter boundary.

Use resolved policies and evidence to justify the simplest viable selection; do not treat prototype technology as a binding production decision. Identify any necessary follow-on research before choosing. Record only costly/surprising trade-offs as ADRs. The answer must be an implementable architecture and configuration boundary, not provisioning or production code.

Include all three allocation policies and both purchase modes. Use Define allocation policies and organizer-triggered shuffling, Define central-purchase workflow and fulfillment, and Define upfront-payment tracking and refunds for central purchases as policy inputs rather than choosing their behavior through implementation. Cover the durable organizer-triggered initial shuffle and fixed order across arrivals, retries, and restarts, exclusive organizer purchase claims, purchase outcomes, payment matching/corrections, committed funds, and refund history with the agreed access boundaries. Settle the bank-operation boundary only after the funding decision chooses manual tracking/import/integration; do not silently assume a banking API or automated seller checkout. The mail contract must support the agreed recipient-mail-server acceptance evidence for self-purchase fulfillment or explicitly surface a capability mismatch.

Part of #1 ## Question Which stack and operating contract best implement the agreed specification for a self-hosted, single-hackerspace web application? There are no existing backend, database, deployment, mail, or OAuth-provider constraints. Compare a small number of concrete options for application runtime, durable queue/assignment storage and concurrency, inbound/outbound mail, background processing, authentication, PWA push, and deployment. Cover idempotency and durable dispatch, configuration/secret ownership, backups and restore, monitoring of stalled distribution, and the event-adapter boundary. Use resolved policies and evidence to justify the simplest viable selection; do not treat prototype technology as a binding production decision. Identify any necessary follow-on research before choosing. Record only costly/surprising trade-offs as ADRs. The answer must be an implementable architecture and configuration boundary, not provisioning or production code. Include all three allocation policies and both purchase modes. Use [Define allocation policies and organizer-triggered shuffling](https://git.s1q.dev/MISChaufen/prevouch/issues/14), [Define central-purchase workflow and fulfillment](https://git.s1q.dev/MISChaufen/prevouch/issues/15), and [Define upfront-payment tracking and refunds for central purchases](https://git.s1q.dev/MISChaufen/prevouch/issues/16) as policy inputs rather than choosing their behavior through implementation. Cover the durable organizer-triggered initial shuffle and fixed order across arrivals, retries, and restarts, exclusive organizer purchase claims, purchase outcomes, payment matching/corrections, committed funds, and refund history with the agreed access boundaries. Settle the bank-operation boundary only after the funding decision chooses manual tracking/import/integration; do not silently assume a banking API or automated seller checkout. The mail contract must support the agreed recipient-mail-server acceptance evidence for self-purchase fulfillment or explicitly surface a capability mismatch.

phg added the

wayfinder:grilling

needs-info

labels

2026-10-20 21:29:41 +00:00

phg added a new dependency

2026-10-20 21:29:44 +00:00

#5 Define ticket-request allocation and fulfillment

phg added a new dependency

2026-10-20 21:29:44 +00:00

#6 Choose successor routing and incoming-voucher trust rules

phg added a new dependency