chore: remove MVP positioning and align plan defaults (#15)
## Summary - remove MVP wording from repository docs and guidance - rename the system plan document and update references to it - align the default subscription plan code/name with product wording - document hard subscription expiry with no grace period ## Verification - docker build -f infra/docker/web.Dockerfile . - docker build -f infra/docker/migrate.Dockerfile . Co-authored-by: sirily <sirily@git.shararam.party> Reviewed-on: #15
This commit was merged in pull request #15.
This commit is contained in:
@@ -6,7 +6,7 @@ Deploy on one VPS with Docker Compose.
|
||||
## Why this target
|
||||
- The system has multiple long-lived components: web, worker, bot, database, and reverse proxy.
|
||||
- Compose gives predictable service boundaries, easier upgrades, and easier recovery than manually managed host processes.
|
||||
- It keeps the path open for later separation of web, worker, and bot without reworking the repository layout.
|
||||
- It preserves clear service boundaries if separation is ever needed later.
|
||||
|
||||
## Expected services
|
||||
- `migrate`: one-shot schema bootstrap job run before app services start
|
||||
@@ -22,7 +22,7 @@ Deploy on one VPS with Docker Compose.
|
||||
- Keep persistent data in named volumes or external storage.
|
||||
- Keep secrets in server-side environment files or a secret manager.
|
||||
- Back up PostgreSQL and object storage separately.
|
||||
- Prefer Telegram long polling in MVP to avoid an extra public webhook surface for the bot.
|
||||
- Prefer Telegram long polling to avoid an extra public webhook surface for the bot.
|
||||
|
||||
## Upgrade strategy
|
||||
- Build new images.
|
||||
@@ -33,7 +33,7 @@ Deploy on one VPS with Docker Compose.
|
||||
## Current database bootstrap state
|
||||
- The current Compose template runs a `migrate` service before `web`, `worker`, and `bot`.
|
||||
- The job runs `prisma migrate deploy` from the committed migration history.
|
||||
- The same bootstrap job also ensures the default MVP `SubscriptionPlan` row exists after migrations.
|
||||
- The same bootstrap job also ensures the default `SubscriptionPlan` row exists after migrations.
|
||||
- Schema changes must land with a new committed Prisma migration before deployment.
|
||||
|
||||
## Initial operational checklist
|
||||
|
||||
@@ -1,15 +1,15 @@
|
||||
# MVP System Plan
|
||||
# System Plan
|
||||
|
||||
## Summary
|
||||
Build `nproxy`, a B2C web product for image generation through external model APIs. The first model is `nano_banana`. Users register with `email + password`, pay a monthly crypto subscription, receive a monthly request limit, and use a chat-style interface for `text-to-image` and `image-to-image` generation.
|
||||
|
||||
The service hides provider-key failures behind a routed key pool. A user request is attempted against one provider key at a time. Retryable failures move execution to the next eligible key. The user sees an error only after all eligible keys have been exhausted or the request fails for a terminal user-caused reason.
|
||||
|
||||
## Confirmed MVP decisions
|
||||
## Confirmed product decisions
|
||||
- One B2C website.
|
||||
- One monthly subscription plan.
|
||||
- Crypto checkout through a payment processor.
|
||||
- Manual renewal in MVP.
|
||||
- Manual renewal.
|
||||
- Text-to-image and image-to-image.
|
||||
- User-facing synchronous experience implemented with polling over background execution.
|
||||
- Approximate quota buckets only: `100/80/60/40/20/0`.
|
||||
@@ -45,7 +45,8 @@ The service hides provider-key failures behind a routed key pool. A user request
|
||||
- notifications
|
||||
|
||||
## Billing rules
|
||||
- One active plan in MVP.
|
||||
- One active plan.
|
||||
- Access ends immediately when `currentPeriodEnd` is reached. Warnings may be sent beforehand, but there is no grace period after expiry.
|
||||
- Each user has an individual billing cycle based on successful activation timestamp.
|
||||
- Limit resets on each successful cycle activation.
|
||||
- One successful generation consumes one request.
|
||||
@@ -60,7 +61,7 @@ Backend tracks exact usage. Normal users see only an approximate bucket:
|
||||
- `1-20%` remaining -> `20%`
|
||||
- `0%` remaining -> `0%`
|
||||
|
||||
## Generation controls in MVP
|
||||
## Generation controls
|
||||
- mode: `text_to_image` or `image_to_image`
|
||||
- resolution preset
|
||||
- batch size
|
||||
@@ -94,8 +95,8 @@ Single VPS with Docker Compose, expected services:
|
||||
- `caddy` or `nginx`
|
||||
- optional `minio` when object storage is self-hosted
|
||||
|
||||
## Future-compatible boundaries
|
||||
The codebase should be able to add later:
|
||||
## Optional extensions
|
||||
These are not current commitments. Consider them only if user demand, operational need, and product scale justify the added complexity:
|
||||
- more image providers
|
||||
- more billing methods
|
||||
- more subscription plans
|
||||
Reference in New Issue
Block a user