V1.0 ROADMAP TODOS - nself-org/cli GitHub Wiki
Document type: Engineering roadmap Scope: Planned source-level enhancements identified during v0.9.x development Target release: v1.0.0 LTS (Q1 2026) Status: All items are tracked, prioritized, and assigned to a release milestone
During the development of the v0.9.x series, the nself engineering team annotated the source code with TODO and FIXME markers to flag planned enhancements that were intentionally deferred to v1.0. These are not bugs. Every one of the 15 items below represents a deliberate design decision: ship a working, tested implementation first, then harden it to production-grade quality before the LTS release.
This document catalogs all 15 items, groups them by subsystem, and clarifies the distinction between v1.0 launch blockers (items that must ship in v1.0.0) and v1.0+ post-launch enhancements (items targeted for the v1.1 or v1.2 cycle).
| # | Item | Subsystem | File | Priority | Milestone |
|---|---|---|---|---|---|
| 1 | Session management improvements (AUTH-004) | Authentication | auth-manager.sh |
High | v1.0 |
| 2 | bcrypt password hashing | Authentication | auth-manager.sh |
Critical | v1.0 |
| 3 | bcrypt password verification | Authentication | auth-manager.sh |
Critical | v1.0 |
| 4 | OAuth login flow completion | Authentication | auth-manager.sh |
High | v1.0 |
| 5 | Session persistence and refresh logic | Authentication | auth-manager.sh |
High | v1.0 |
| 6 | Additional OAuth provider support | Authentication | auth-manager.sh |
Medium | v1.0+ |
| 7 | JWT signing with RSA/ECDSA private key | Authentication | jwt-manager.sh |
Critical | v1.0 |
| 8 | Tenant-specific SMTP config from database | White-Label | email-templates.sh |
High | v1.0 |
| 9 | Plugin marketplace ratings API | Plugin Ecosystem | registry.sh |
Medium | v1.0+ |
| 10 | Plugin upload API | Plugin Ecosystem | registry.sh |
Medium | v1.0+ |
| 11 | Plugin issue reporting API | Plugin Ecosystem | registry.sh |
Medium | v1.0+ |
| 12 | GPG signature verification for plugins | Plugin Ecosystem | core.sh |
High | v1.0 |
| 13 | Email service integration for invoice delivery | Billing | invoices.sh |
High | v1.0 |
| 14 | Notification system integration for quota alerts | Billing | quotas.sh |
High | v1.0 |
Legend: Critical = launch blocker with security or data-integrity implications. High = launch blocker that affects user-facing correctness. Medium = post-launch enhancement.
These items must be complete before v1.0.0 ships. They fall into two categories:
Security hardening โ Items 2, 3, and 7 affect credential storage and token signing. Shipping v1.0 without proper bcrypt hashing or RSA/ECDSA JWT signing would expose deployments to known attack vectors. These are the highest-priority items on this list.
Functional completeness โ Items 1, 4, 5, 8, 12, 13, and 14 represent features that exist in partial form. The current implementations are correct for development environments but are not suitable for production without the planned hardening.
Items 9, 10, and 11 relate to the plugin marketplace backend โ a server-side API that does not yet exist. The current implementations use GitHub-native workflows (stars, pull requests, and issues) as a functional substitute. This approach works correctly; replacing it with a dedicated marketplace API is a quality-of-life improvement that can ship in the v1.1 cycle without affecting any existing functionality.
Source file: src/lib/auth/auth-manager.sh
| Field | Detail |
|---|---|
| Description | The current session management implementation covers the core lifecycle (create, validate, expire) but does not yet implement the full AUTH-004 spec: concurrent session limits per user, device-level session tracking, and admin-initiated session revocation across all devices. |
| File | src/lib/auth/auth-manager.sh |
| Priority | High |
| Milestone | v1.0 |
| User impact | Multi-tenant deployments need per-user session controls for compliance and security auditing. Without this, administrators cannot force-logout compromised accounts across all active sessions. |
| What it enables | GDPR-compliant session management, enterprise audit trails, device management UI in nself-admin. |
| Field | Detail |
|---|---|
| Description | The current password storage path hashes passwords using a portable but less robust algorithm. The v1.0 implementation will replace this with bcrypt (via htpasswd -B or a thin wrapper) to meet the industry-standard baseline for password storage. |
| File | src/lib/auth/auth-manager.sh |
| Priority | Critical |
| Milestone | v1.0 |
| User impact | Passwords stored before this change are not bcrypt-hashed. A migration path will be provided so that hashes are upgraded on next login. |
| What it enables | Industry-standard password security. Required before nself can be deployed in any SOC 2, HIPAA, or PCI-DSS context. |
| Field | Detail |
|---|---|
| Description | Paired with Item 2: the password verification path must be updated to verify bcrypt hashes correctly. The current verifier will remain in place during the migration window to handle legacy hashes, then be removed once all hashes have been upgraded. |
| File | src/lib/auth/auth-manager.sh |
| Priority | Critical |
| Milestone | v1.0 |
| User impact | Zero downtime during migration โ users with legacy hashes continue to log in while their hash is silently upgraded on successful verification. |
| What it enables | Completes the bcrypt migration started in Item 2. |
| Field | Detail |
|---|---|
| Description | The OAuth login flow currently handles the authorization code exchange and token storage but does not yet implement the full PKCE extension for public clients, or handle token refresh on expiry during an active session. |
| File | src/lib/auth/auth-manager.sh |
| Priority | High |
| Milestone | v1.0 |
| User impact | Mobile and SPA clients using OAuth without a client secret require PKCE. Without it, the authorization code is vulnerable to interception. |
| What it enables | Secure OAuth for public clients (mobile apps, SPAs). Required for production deployments with external identity providers. |
| Field | Detail |
|---|---|
| Description | Sessions are currently held in memory and do not survive a service restart. The v1.0 implementation will persist session state to PostgreSQL and implement sliding-window refresh so that active users are not logged out unexpectedly. |
| File | src/lib/auth/auth-manager.sh |
| Priority | High |
| Milestone | v1.0 |
| User impact | Any service restart currently invalidates all active sessions. In production, this means users are logged out on every deployment. |
| What it enables | Zero-interruption deployments from an authentication perspective. Required for the zero-downtime deployment guarantee in v1.0. |
| Field | Detail |
|---|---|
| Description | The current OAuth implementation ships with 13 providers. This item tracks expanding that list with additional enterprise identity providers (SAML-to-OAuth bridges, enterprise social logins) requested by early adopters. |
| File | src/lib/auth/auth-manager.sh |
| Priority | Medium |
| Milestone | v1.0+ |
| User impact | Additive โ does not affect existing providers. Expands the set of identity providers available without any configuration changes for current users. |
| What it enables | Broader enterprise SSO compatibility in the v1.1 cycle. |
Source file: src/lib/auth/jwt-manager.sh
| Field | Detail |
|---|---|
| Description | Security critical. The current JWT implementation signs tokens with a symmetric HMAC key (HS256). The v1.0 implementation will add support for asymmetric signing using RSA (RS256) or ECDSA (ES256) private keys, which is required for any deployment where a third-party service needs to verify tokens without access to the signing secret. |
| File | src/lib/auth/jwt-manager.sh |
| Priority | Critical |
| Milestone | v1.0 |
| User impact | Deployments that share JWTs with external services (CDNs, serverless functions, microservices) currently require those services to hold the symmetric secret โ a poor security posture. Asymmetric signing allows the public key to be distributed freely. |
| What it enables | Proper JWT federation across services. Required for Hasura JWT integration in its recommended configuration. A prerequisite for enterprise-grade multi-service architectures. |
Source file: src/lib/whitelabel/email-templates.sh
| Field | Detail |
|---|---|
| Description | The email template system currently uses a single global SMTP configuration for all tenants. The v1.0 implementation will fetch per-tenant SMTP settings from the database at send time, allowing each tenant to send email from their own domain and mail server. |
| File | src/lib/whitelabel/email-templates.sh |
| Priority | High |
| Milestone | v1.0 |
| User impact | Without per-tenant SMTP, all outbound email (password resets, notifications, invoices) comes from the platform operator's mail server. For white-label deployments, this breaks the customer's brand experience and can cause deliverability issues. |
| What it enables | True white-label email: tenants configure their own SMTP credentials and all platform email is sent on their behalf. A core requirement for the white-label feature set. |
Source files: src/lib/plugin/registry.sh, src/lib/plugin/core.sh
| Field | Detail |
|---|---|
| Description | Plugin ratings are currently determined by GitHub star count on the plugin's repository. The v1.0+ implementation will replace this with a dedicated marketplace API that collects and aggregates verified install-based ratings, providing more meaningful quality signals. |
| File | src/lib/plugin/registry.sh |
| Priority | Medium |
| Milestone | v1.0+ |
| User impact | The current GitHub-stars approach works correctly. The marketplace API will improve signal quality but is not a blocker for any existing functionality. |
| What it enables | A curated plugin quality signal independent of GitHub engagement metrics. Enables verified ratings from confirmed installs. |
| Field | Detail |
|---|---|
| Description | Plugin authors currently submit plugins by opening a pull request to the nself-plugins repository. The v1.0+ implementation will provide a dedicated upload API and CLI workflow (nself plugin publish) backed by a marketplace backend. |
| File | src/lib/plugin/registry.sh |
| Priority | Medium |
| Milestone | v1.0+ |
| User impact | The PR-based workflow works correctly and will remain available. The upload API improves the developer experience for plugin authors and enables automated validation pipelines. |
| What it enables | Self-service plugin publishing, automated security scanning on upload, versioned release management through the marketplace. |
| Field | Detail |
|---|---|
| Description | Plugin issues are currently reported via GitHub Issues on the nself-plugins repository. The v1.0+ implementation will provide an in-CLI issue reporting path (nself plugin report) that routes reports through the marketplace API to the correct plugin author. |
| File | src/lib/plugin/registry.sh |
| Priority | Medium |
| Milestone | v1.0+ |
| User impact | GitHub Issues remain fully functional. This is a convenience improvement that reduces friction for users who encounter issues with third-party plugins. |
| What it enables | Structured issue routing to plugin authors, in-CLI feedback without leaving the terminal, and aggregate issue tracking across the plugin ecosystem. |
| Field | Detail |
|---|---|
| Description | The plugin installer downloads and executes shell code. The v1.0 implementation will verify a GPG signature on every plugin archive before execution, ensuring that the installed code has not been tampered with since it was published. |
| File | src/lib/plugin/core.sh |
| Priority | High |
| Milestone | v1.0 |
| User impact | Without signature verification, a compromised plugin registry or a man-in-the-middle attack could deliver malicious code to the installer. This is a supply-chain security requirement for any production deployment. |
| What it enables | Cryptographically verified plugin installation. Users can confirm that installed plugins exactly match what the author published. Required for enterprise and compliance-sensitive deployments. |
Source files: src/lib/billing/invoices.sh, src/lib/billing/quotas.sh
| Field | Detail |
|---|---|
| Description | Invoices are currently generated and stored but not automatically emailed to tenants. The v1.0 implementation will integrate with the configured email service (the same SMTP stack used by the white-label email system) to deliver invoices to the tenant billing contact on generation and on payment events. |
| File | src/lib/billing/invoices.sh |
| Priority | High |
| Milestone | v1.0 |
| User impact | Tenants must currently download invoices manually from the billing dashboard. Automated invoice delivery is a baseline expectation for any billing system used in a production SaaS context. |
| What it enables | Automated invoice delivery on generation, on payment, and on payment failure. Required for billing compliance in most jurisdictions. |
| Field | Detail |
|---|---|
| Description | Quota usage is tracked and enforced but alerts are currently only surfaced in the nself-admin dashboard. The v1.0 implementation will route quota threshold events (e.g., 80% and 100% of storage or API call limits) through the notification system to deliver alerts via email, webhook, or configured channel. |
| File | src/lib/billing/quotas.sh |
| Priority | High |
| Milestone | v1.0 |
| User impact | Without proactive quota alerts, tenants discover they have hit a limit only when a request is rejected. Proactive notification allows operators to respond before service is interrupted. |
| What it enables | Proactive quota management. Tenants receive warnings before hitting hard limits, reducing surprise service interruptions. Enables webhook-based quota events for integration with external monitoring systems. |
- All 15 items are annotated in source with
# TODOor# FIXMEcomments at their exact implementation point. Search for these markers in the relevant files to find where to begin. - Items 2, 3, and 7 are the highest-priority items and should be worked on first within the authentication subsystem. They have direct security implications.
- Items 9, 10, and 11 depend on the marketplace backend API being provisioned. They are deliberately scoped to v1.0+ and should not block the v1.0.0 release.
- The current implementations behind each of these TODOs are functional and tested. The enhancements described here are additions and hardening โ they do not require rewriting the surrounding logic.
- When implementing any item, follow the Code-Docs-Commit workflow: implement in
src/lib/, update the relevant.wiki/page, and commit code and docs together.
This document is generated from source-level annotations as of v0.9.9. It will be updated as items are completed during the v1.0 development cycle.
Last updated: 2026-02-21