ahmido
1f3a8b5ed9
Added comprehensive documentation and planning artifacts for the platform productization readiness and roadmap reconciliation. Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #417
62 lines
2.9 KiB
Markdown
62 lines
2.9 KiB
Markdown
# App Boundary Map — Spec 345
|
|
|
|
**Branch**: `345-platform-productization-readiness-roadmap-reconciliation-gate`
|
|
**Date**: 2026-06-02
|
|
|
|
## Belongs in `/platform`
|
|
|
|
- Internal MSP/operator control-plane work:
|
|
- Governance Inbox and Decision Register follow-through
|
|
- Findings, accepted-risk, and review/workflow closure
|
|
- Provider connections, onboarding readiness, required permissions, and safe integration recovery
|
|
- Evidence overview, review packs, stored reports, audit log, and retained-artifact truth
|
|
- Monitoring, operations, alerts, and cross-domain indicator semantics
|
|
- Customer-safe output preparation inside operator-managed flows
|
|
- Practical rule:
|
|
- customer-safe summaries may be rendered inside `/platform` while the operator plane is still the product of record
|
|
- this does **not** make `/platform` the customer portal
|
|
|
|
## Belongs in `/customerportal`
|
|
|
|
- External customer-consumption surfaces that should consume already-stable platform outputs instead of re-implementing them:
|
|
- customer-facing review history
|
|
- customer-facing evidence/review-pack download center
|
|
- external accepted-risk / acknowledgement consumption if ever moved outside the operator plane
|
|
- branded customer document library and follow-up intake
|
|
- any future `Virtual Consultant / External Portal Guidance` runtime
|
|
- Boundary rule:
|
|
- do not implement these inside Filament `/platform`
|
|
- prepare the output contracts first in `/platform`, then expose them in `/customerportal`
|
|
|
|
## Belongs in `/website`
|
|
|
|
- Public marketing and acquisition work:
|
|
- pricing
|
|
- product pages
|
|
- public docs or public knowledge pages
|
|
- lead capture / waitlist / demo request
|
|
- public trust-pack style content
|
|
- Boundary rule:
|
|
- no marketing/public lead-gen surface should be hidden inside the operator platform backlog
|
|
|
|
## Belongs in `/system`
|
|
|
|
- Platform-operator and break-glass work:
|
|
- support-access governance and support access history
|
|
- workspace directory / closure / commercial truth mutation surfaces
|
|
- global ops and break-glass tooling
|
|
- other platform-owner-only administration that should not live in tenant/workspace operator flow
|
|
|
|
## Deferred (explicit)
|
|
|
|
- `/customerportal` as a product line is explicitly deferred until the operator platform outputs are calmer and more stable.
|
|
- Customer billing/self-serve portals are deferred; current commercial truth belongs in operator/system workflows.
|
|
- External portal guidance, customer self-serve evidence history, and customer-facing workflow intake stay deferred even when customer-safe summaries already exist in `/platform`.
|
|
- AI-visible customer-facing portal behavior stays deferred until a first governed runtime AI consumer exists inside the platform.
|
|
|
|
## Current Boundary Judgment
|
|
|
|
- The next spec should stay in `/platform`.
|
|
- The next spec should **not** start `/customerportal`.
|
|
- Existing customer-safe review work inside `/platform` should be treated as operator-managed output preparation, not as a hidden portal bootstrap.
|