developer-portal — Roadmap / Backlog
Filed: 2026-05-27 (vision pass + Option C / Phase-2 / Phase-3 addendum).
Umbrella: mahmoudholding/developer-portal#13 — Developer Portal Vision.
Label: devportal-vision (applied across all 6 repos).
This is the backlog of issues filed during the 2026-05-27 vision pass, grouped by category. Each item links to the GitHub issue. Owner-gated decisions are flagged in docs/human-actions.md.
(a) Public docs site + landing
- dp#14 — Public docs site + landing reflecting vision. Landing page renders the Option C neutral brand; per-product sections are clearly named.
(b) Developer sign-up / sign-in (docs stay public)
- dp#15 — One portal account across products; docs remain unauthenticated. Sign-in only required for account/keys.
(c) Per-product API key issuance UI + storage
- dp#16 — Portal UI to mint per-product keys; keys persist in each product backend's DB so they migrate cleanly on phase-3 spin-out.
(e) OpenAPI spec ingestion pipeline
- dp#17 — Each product CI publishes OpenAPI on release; portal pulls and rebuilds the affected section. Designed so a phase-3 spin-out swaps the source URL without re-architecting the portal.
(f) Try-it-out renderer choice
- dp#18 — Redoc (read-only) vs Swagger UI vs Stoplight Elements vs hybrid. Whichever wins is mounted per endpoint inside the product section.
(g) Sandbox / staging access for developers
- dp#19 — Each product exposes a sandbox the portal can route developers to. Sandbox keys minted on sign-in to prevent abuse.
(h) Status page + changelog + migration guides
- dp#20 — Per-product status, changelog, and migration guides. Authored by each product team and surfaced inside that product's section.
(i) Legal — ToS + Privacy + DPA
- dp#21 — Terms of Service, Privacy Policy, and DPA naming Mahmoud Consultancy B.V. as GDPR controller. Per-product processing addenda layer on top. Owner sign-off required (see human-actions).
(j) Branding decision + consistent application
- dp#22 — Decision: Option C (neutral "Developer Portal" wrapper with per-product sections), per owner addendum 2026-05-27. Phase-2 ("product of GloryLabs" positioning) and phase-3 (spin-out to
developer.<product>.com) URL plan documented in architecture.md.
Cross-product middleware (one issue per product repo)
The portal mints keys; each product backend validates them via a shared middleware library. One issue per product:
- auditPic: #130 — API-key validation middleware (portal-issued keys).
- claimio: #142 — API-key validation middleware.
- europeLogin: #115 — API-key validation middleware.
- mahmoud-consultancy: #218 — API-key validation middleware.
- valideerleeftijd: #95 — API-key validation middleware.
All five are labelled devportal-vision in their respective repos and reference the umbrella issue dp#13.
Sequencing (not committed dates — owner-gated)
A rough order, but each step is its own owner-gated decision; nothing here implies a timeline.
- Foundations: dp#14 landing + Option C styling (dp#22 already decided).
- Spec pipeline: dp#17 — pick a mechanism; one product (proposal: auditPic) becomes the pilot publisher.
- Auth + keys: dp#15 + dp#16 — portal sign-in, portal-side issuance UI, per-product backend storage. Land the cross-product middleware issues in parallel.
- Try-it-out: dp#18 — pick the renderer; mount per endpoint.
- Sandbox: dp#19 — wire each product's staging URL into its section.
- Status / changelog: dp#20.
- Legal: dp#21 — needs owner sign-off on controller designation and per-product DPAs.
Phase-2 / phase-3 work (positioning copy, spin-out redirect rules) is not a separate workstream — it's a constraint each item already accommodates per the architecture doc.
Reacties