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:
2026-03-10 15:01:06 +03:00
parent ba029d8f3f
commit 55472de23d
11 changed files with 73 additions and 26 deletions

View File

@@ -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

View File

@@ -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