Internal Documentation internal
← Back to TalkIDE
TalkIDE internal documentation

This document tracks known MVP limitations, stubs, and out-of-scope features. Check this before implementing or testing features that may depend on unfinished functionality.

Last updated: 2026-05-23

Active Limitations

Stripe Billing — Test Mode Only (Stopa C)

  • Status: Partially implemented (Stopa C, UC-10001–UC-10007)

  • Detail: Stripe integration is implemented in test mode only — no real money flows. After Stopa C is deployed, the following billing features are real (no longer mockup):

    • Payment method — Stripe SetupIntent flow, card registration via Stripe Elements (UC-10001). Displayed card (brand, last4, expiry) is from live Stripe Customer data (UC-10002).
    • Billing email — editable, persisted to Stripe Customer object (UC-10003).
    • Invoices — fetched from Stripe Invoices API, paginated, with PDF download link (UC-10004).
    • Spending limit — user_budget.spending_limit_usd column, GET/PUT via BudgetController, soft alert at 80 % and 100 %, Mara soft-stop at 100 % (UC-10005).
    • Stripe webhook — POST /api/v1/stripe/webhook processes payment_method.attached, customer.updated, invoice.paid, invoice.payment_failed, invoice.voided, payment_intent.succeeded, payment_intent.payment_failed (UC-10006, UC-10007).
    • Credit top-up — jednorázové dobití AI kreditu zvolenou částkou ($5–$500) přes Stripe PaymentIntent s uloženou kartou (test mode). Kredit je připsán asynchronně po potvrzení Stripe webhookem (payment_intent.succeeded). Tabulka credit_topup (migrace 0027) sleduje stav PENDING → SUCCEEDED / FAILED. FE může pollovat stav přes GET /api/v1/users/me/billing/topup/{id}/status (UC-10007).

    Still not implemented after Stopa C + top-up:

    • Real money / live Stripe mode — requires explicit go-live switch (Stripe test → live keys).
    • Actual email sending for billing alerts (stub: Slf4j log only in MVP — billing alert e-mail is out of scope for ADR-025 Mailgun integration; planned as Stopa C follow-up).
    • Hosting cost billing (agent compute fees, hosting hours) — separate future effort.
    • Tax / VAT ID field — still mockup in UI, no backend.
    • Subscription / recurring billing — no Stripe Products or Prices used; payment method on file only.
    • Auto-recharge (automatic top-up when balance drops below threshold) — not planned in MVP.
    • Fixed credit packages / bundles — top-up is free-form amount only.

  • Impact: Users can register a test card and see invoice history. Spending limit is enforced as a soft cap. No real charges occur until Stripe live mode is activated (separate release).

Profile Settings Hub — Billing Section Status After Stopa C (UC-01006)

  • Status: Partially real after Stopa C — 5 of 8 billing rows are real API

  • Detail: After Stopa C deployment, the Billing & Usage section in BillingSection.vue connects to real backend APIs for:

    • Payment method display and registration (UC-10001, UC-10002)
    • Billing email (UC-10003)
    • Invoice list (UC-10004)
    • Spending limit (UC-10005)
    • AI usage quota bars (UC-08006, already real)
    • Credit top-up — “Add credit” button, amount input, PaymentIntent flow, status polling (UC-10007)

    Still mockup / not implemented:

    • Estimated cost card (hosting hours, agent compute breakdown)
    • Tax / VAT ID field
    • Notification preference toggles (Notifications section, separate feature)

  • Impact: The previously fully-mocked Billing section is now largely functional. Users experience a real billing workflow backed by Stripe test mode.

No Live Technician Support UI

  • Status: Not implemented (MVP)
  • Detail: Live technician support is a planned monetization feature where a human expert can join a user’s session. The backend model does not yet include support sessions or technician accounts.
  • Impact: Users can only interact with the AI PM; no human escalation path.

Claude Code CLI and Network Worker Must Be Available

  • Status: External dependency (MVP / production)
  • Detail: TalkIDE depends on either Claude Code CLI (lokální vývoj, Max plán) nebo talkide-worker Node.js pod (cloud / produkce, ADR-024) being available and authenticated. The backend communicates with the network worker via HTTP+SSE; if worker pod není připraven nebo identity token je prošlý, vibecoding selže.
    • executor.type = CLI — vyžaduje nainstalovaný a autentizovaný claude CLI (local dev)
    • executor.type = NETWORK_WORKER (default a prod) — vyžaduje běžící talkide-worker pod v tenant-env namespace, validní TALKIDE_WORKER_IDENTITY_TOKEN v K8s Secret talkide-worker-token a dosažitelný control-plane BE pro mint endpoint
  • Impact: First-time setup requires worker pod provisioning (handled automatically by K8sWorkerProvisioner on first conversation turn); worker pod restart recovers from NFS session state (viz worker-runtime.md).

Concierge Panel — Mockup Only

  • Status: Frontend mockup — no backend connection

  • Detail: The Concierge panel (support/chat widget in the bottom-right corner of the UI) is entirely static — no backend endpoint exists, no messages are sent or received. All other major screens are connected to real backend APIs with real AI integration:

    Fully implemented (real backend API + real Mara responses):

    • Projects screen — project list loaded from API; search, filter, sort, and grid/list view operate on real project data
    • New Project screen — form submits to API and creates a real project record
    • Studio Dashboard — project list/grid and activity feed loaded from API
    • Workspace (chat) — conversation API connected; users can start conversations, send messages, view message history. Mara responses are real AI responses via Anthropic (no mock). Conversation history panel shows past conversations.

    Still mockup / static:

    • Concierge panel — entirely static; no backend connection; planned as paid live-technician support feature

  • Impact: Users can create, list, and manage projects via a real backend. Users can have real AI-powered conversations with Mara. Only the Concierge support widget remains non-functional until implemented.

Profile Settings Hub — Partially Mockup (UC-01006)

  • Status: Partial — 3 of 7 sections use real APIs after Stopa C (Billing section upgraded); 4 sections remain frontend mockup

  • Detail: The My Profile screen is a full-page settings hub with 7 sections. After Stopa C:

    • Profile section — display name and email via GET /api/v1/users/me and PUT /api/v1/users/me — real
    • Account section — password change via PUT /api/v1/users/me/password; language picker via PUT /api/v1/users/me/locale — real
    • Billing & usage — payment method, billing email, invoices, spending limit backed by Stripe APIs (UC-10001–UC-10005); AI quota bars real via UC-08006. Estimated cost card and Tax/VAT ID still mockup. — partially real after Stopa C

    The remaining 4 sections are frontend mockups with static/hardcoded data:

    • Notifications — no notification preferences API; toggle states are local component state only
    • Team — no collaborator/invite API; collaborator list and invite flow are static
    • Connected accounts — no OAuth account management API; connect/disconnect buttons are non-functional
    • Danger zone — export and account deletion are not implemented

    Additional fields in the Profile section (handle, role, bio, website, social links, “currently working with” tags) are displayed in the UI but not yet persisted via API.

  • Impact: After Stopa C, users can register a payment method, manage billing email, view invoices, and set a spending limit. Profile and Account sections remain real. Notifications, Team, Connected accounts, and Danger zone remain visual-only.

Single-pod assumption pro real-time stream (SSE)

  • Status: By design (MVP) — single instance

  • Detail: ActivityEventBus je in-memory pub/sub běžící uvnitř JVM procesu. SSE klient připojený k podu A dostane pouze události publikované na témž podu A — události vzniklé na jiných podech se k němu nedostanou. Při horizontal scaling (N > 1 pod za load balancerem) by každý SSE klient viděl jen výřez aktivit odpovídající podu, na který byl požadavek nasměrován.

    Stejný charakter má i Caffeine cache projectId → ProjectInfo uvnitř ActivityEventBus: každý pod má vlastní lokální cache. Cold-start cost se násobí počtem podů, ale nejde o korektnostní chybu — cache-aside pattern zajistí, že chybějící záznam se doplní z DB.

    Současný stav: TalkIDE běží na jediném podu, takže toto omezení nemá žádný praktický dopad.

    Před horizontálním škálováním bude nutné zvolit jednu z variant:

    • (a) Sticky sessions — klient je vždy směrován na tentýž pod; křehké řešení, blokuje rolling deploy a zero-downtime aktualizace.
    • (b) Distribuovaný event bus (Redis pub/sub, RabbitMQ, NATS) — preferovaná varianta; všechny pody publikují do sdíleného brokeru a každý pod doručí události svým SSE klientům.
    • (c) Centralizovaný event-router pod — single point of failure, nedoporučeno.

    Plánované řešení: V rámci UC-08 (Mara Platform) zavádíme Redis pro FUP quota tracking. Stejná Redis instance může sloužit jako distributed event bus (pub/sub) — preferovaná varianta (b) z výše uvedených. Follow-up po dokončení UC-08001 a UC-08002.

  • Impact: Týká se UC-05001 (workspace activity feed) a UC-06001 (Studio recent activity). V MVP bez horizontálního škálování je dopad nulový.

Waitlist “Copied!” Feedback Missing in HTTP Context

  • Status: Known cosmetic limitation, follow-up tracked (GitLab issue v talkide-fe)
  • Detail: Na success obrazovce waitlistu po kliknutí na “Copy” u invite linku se nezobrazí vizuální “Copied!” feedback, pokud běží stránka v HTTP (např. localhost dev / lokální E2E). navigator.clipboard.writeText() je prohlížečem blokována mimo secure context (non-HTTPS). Samotná clipboard akce má execCommand fallback, ale UI “Copied!” indikace se při selhání clipboard API nezobrazí.
  • Impact: Pouze HTTP/localhost. V produkci (https://talkide.app, secure context) clipboard API funguje a feedback se zobrazuje normálně. Žádný dopad na produkční uživatele.
  • TODO: Frontend — zobrazit “Copied!” feedback i při selhání clipboard.writeText (graceful degradation přes execCommand path).

BOGO Credit Bonus — Threshold nelze měnit přes UI (UC-10017)

  • Status: By design (MVP) — admin UI pro pricing_markup_config zatím neexistuje
  • Detail: Threshold bogo_max_generation v tabulce pricing_markup_config nelze měnit přes žádné administrátorské UI. Admin musí editovat přímo v DB: 
    UPDATE pricing_markup_config SET bogo_max_generation = X;
    Hodnoty se projeví okamžitě (bez redeploye) — PricingMarkupConfigRepository čte singleton row read-through (bez cache). Rezervovaná hodnota -1 = BOGO zcela vypnuto (podmínka invite_generation <= -1 nikdy nenastane, protože invite_generation >= 0).
  • Důvod: Admin UI pro pricing_markup_config (marže / BOGO threshold) nebylo součástí scope UC-10008 (Apply Markup to Billing). Přímá DB editace je dostačující pro alfa fázi s omezeným počtem adminů.
  • Follow-up: Rozšířit admin UI z UC-10008 o pole bogo_max_generation (číselné pole s validací >= -1). Otevřít jako follow-up issue k UC-10017.
  • Impact: Pouze admin operace. Běžní uživatelé ani BOGO logika samotná nejsou ovlivněni — threshold se čte korektně při každém payment_intent.succeeded webhookem.

Transactional E-mail — Mailgun Integration (ADR-025)

  • Status: Implemented for waitlist confirmation (UC-11001) and forgot-password reset link (UC-01005). See ADR-025.
  • Detail: E-mail is sent via Mailgun HTTP API from noreply@mail.talkide.app (sender name: TalkIDE). EmailSender abstraction with MailgunEmailSender (prod) and NoOpEmailSender (dev/test). Audit log in email_log table (migration 0028).
  • Residual limitations:
    • DNS prerequisite: prod e-mail delivery requires Mailgun domain verification for mail.talkide.app (SPF, DKIM, tracking CNAME). If DNS records are not verified in Mailgun, no e-mails will be delivered in production even though the code path is active. This is a manual infrastructure step, not a code change.
    • Billing spending alert (UC-10005, 80 %/100 % threshold) — still a Slf4j log stub; e-mail delivery for billing alerts is out of scope for this iteration (Stopa C follow-up).
    • No retry logic in MVP — if Mailgun API returns 5xx, the failure is recorded in email_log with status=FAILED but no automatic retry or dead-letter queue is implemented.

GDPR Features — Export User Data (UC-01008) and Delete Account (UC-01009)

  • Status: Implemented (Stopa D.2, fe#20). Both features are functional after migration 0048 and 0049 are applied.

  • Detail: Two GDPR compliance features are live:

    • Export User Data (UC-01008) — async ZIP export, delivered via email with a 7-day signed download link. Backed by gdpr_export_request table (migration 0048) and DO Spaces platform/exports/ prefix.
    • Delete Account (UC-01009) — 14-day grace period, soft-delete with deletion_requested_at, email undo link, nightly hard purge job. Backed by three new columns in users table (migration 0049).

  • Known limitations:

    • K8s Deployment/Ingress cleanup during hard purge — If the K8s API is unavailable at purge time, published app Deployments and Ingresses are NOT deleted automatically. Manual admin cleanup is required: kubectl delete deployment -n talkide -l talkide.app/user-id={userId}. This is the most significant operational gap; a future follow-up should add a retry queue or reconciler.
    • Stripe invoice retention — Invoices are deliberately NOT deleted from Stripe during hard purge. Czech tax law requires 7-year retention. The Stripe Customer object remains. The local users row is removed; no reference to the Stripe Customer ID is kept post-purge.
    • Cluster B schema drop on PgBouncer error — If the data-plane PgBouncer is unreachable during purge, DROP SCHEMA may fail. Job logs ERROR and continues. Manual cleanup: DROP SCHEMA IF EXISTS tk_t{tenantId}_p{slug}_{env} CASCADE on cluster B (talkide_dataplane).
    • No export during grace period — User is locked out immediately after delete request; cannot submit a new GDPR export. Admin can manually extract data if needed.
    • Mailgun failure = export/purge FAILED — If Mailgun is unavailable, the export job marks status FAILED and no email is sent. The user must re-request from the UI. No silent fallback, no retry queue in MVP.
    • DO Spaces lifecycle policy is bucket-level — ZIP files are cleaned up by a bucket-level lifecycle rule (7 days). This means ALL objects in platform/exports/ are deleted after 7 days regardless of their individual expires_at. If the lifecycle policy is misconfigured, old export ZIPs persist. Monitor via DO Spaces console.

  • Impact: GDPR Article 15 (right of access) and Article 17 (right to erasure) are operationally satisfied. K8s cleanup gap is the main residual risk for published apps of deleted users — admin must perform manual cleanup until the reconciler follow-up is implemented.

GDPR Export — DO Spaces Wiring Pending

  • Status: BE talkide-be#136 follow-up — DOSpacesGdprExportStorage je stub v production
  • Detail: DOSpacesGdprExportStorage.upload() a generateSignedUrl() throwují GdprExportStorageException v production profilu, takže první GDPR export v produkci skončí status=FAILED s errorMessage=“Upload failed, please try again later”. Email se neodešle.
  • Required follow-up: AWS S3 SDK wiring s endpoint override na nyc3.digitaloceanspaces.com, presigned URL pro 7-day expiry.
  • Impact: GDPR export endpoint je k dispozici (request → PENDING → PROCESSING → FAILED), ale uživatel data nedostane dokud SDK wiring není hotov.

Liquibase — production mode (forward-only, immutable)

Status: Resolved — projekt je v PRODUCTION fázi od 2026-05-12.

spring.liquibase.drop-first: false v application-local.yaml. Migrace jsou immutable — nikdy needituj existující changeset soubory v db/changelog/changes/ (rozbil bys checksum). Vždy přidávej nový soubor s dalším pořadovým číslem.

Seed data (9999-test-data.xml, context "dev") jsou taktéž immutable. Další seed data přidávej jako nový soubor 9XXX-test-data.xml (998, 997, …) s context="dev".

Při startu BE Liquibase aplikuje pouze pending changesety — žádný drop, žádný rerun.

Was this page helpful?

Thanks for the feedback.