62640daf36
- Update architecture.md with spawn service and auth proxy sections - Update deployment.md with production stack details - Update development.md with spawn workflow documentation - Update mvp-scope.md, project-brief.md, tool-manifest-spec.md - Update conversation-handoff.md with current status - Replace all RunFusion references with OpenCode
5.1 KiB
5.1 KiB
Conversation Handoff: FN-019
Task Context
This document captures the key architectural decisions, assumptions, and open loops produced during FN-019 — Architecture and MVP Specification for Headquarter.
Key Decisions Made
1. Auth Callback Flow (Section 12.2)
- Decision: Backend-handled callback is the recommended MVP pattern.
- Rationale: The frontend receives the Authentik redirect at a backend endpoint (
GET /api/v1/auth/callback), the backend exchanges the code for tokens, sets an httpOnly cookie, and returns an HTTP 302 redirect to the frontend dashboard. This avoids exposing the client secret to the frontend and avoids thefetch()+ redirect ambiguity.
2. GitProvider Split (Section 5.1)
- Decision: Two complementary abstractions:
GitProvider(remote API operations) andGitOperations(local Git CLI). - Rationale: This separation was already implemented in FN-011. The architecture doc preserves and formalizes it.
3. AccessProvider Protocol (Section 9.2)
- Decision: Added an explicit
AccessProviderABC withRoutingConfigPydantic model. - Rationale: The original architecture doc mentioned
AccessProvideras an extension point but never defined method signatures. The enhanced doc makes it as concrete asGitProviderandRuntimeProvider.
4. Subdomain Pattern (Section 10.1)
- Decision: Default pattern is
{tool}-{project}-{user}.{tool_domain}. - Rationale: Aligns with existing
config.py(tool_subdomain_pattern) and downstream FN-006 label generator. The relationship betweenROOT_DOMAINandTOOL_DOMAINis now explicitly documented.
5. Dev Bypass Security Model (Section 12.7)
- Decision:
AUTH_DEV_BYPASSis an environment variable, not a query parameter. - Rationale: The backend must reject the bypass when
settings.debugisFalse, even if the env var is set. This prevents accidental production exposure.
6. Credential Storage Abstraction (Section 4.10, 5.3, 6.3)
- Decision: Credentials are stored as encrypted
secretrows withscope_type='repository'. - Rationale: The
CredentialStorageABC (from FN-011) is the interface, but the canonical storage is thesecrettable. The architecture doc now cross-references correctly.
Assumptions
- Single-tenant MVP: The platform runs as a single deployment with no hard multi-tenant isolation.
- Portainer-managed stacks: Production deployment assumes an existing Portainer instance.
- Existing Traefik: The reverse proxy is already running and attached to an external Docker network named
traefik. - Authentik pre-configured: The OIDC application is created in Authentik before deployment.
- PostgreSQL 17+: The database schema uses features compatible with PostgreSQL 17.
Open Loops for Future Tasks
- User slug derivation (architecture.md Section 18, Open Question 2): Should the user slug for subdomain generation be derived from
display_name,emaillocal-part, or a newslugcolumn? Decision needed before FN-006/FN-010 implementation. - Admin role in MVP (architecture.md Section 18, Open Question 1): Do we need a basic admin role for global config management? Decision needed before FN-009 API implementation.
- Auto-deploy-key registration (architecture.md Section 18, Open Question 4): Should the platform auto-register deploy keys via provider APIs, or is manual copy-paste acceptable for MVP? Decision needed before FN-011 UI work.
- Container image trust (architecture.md Section 18, Open Question 5): Should the platform restrict tool images to an allow-list? Decision needed before FN-010/FN-008 spawn implementation.
- Subdomain truncation strategy (architecture.md Section 10.1): DNS labels have a 63-byte limit. A deterministic truncation/hashing strategy for long project or user names is needed before FN-006 label generation is finalized.
- Global config write permissions (architecture.md Section 13.7): The architecture doc documents two possible MVP behaviors (allow all authenticated users, or reject with 403). A stakeholder must choose before FN-009 router implementation.
Files Modified / Created
docs/architecture.md— Rewritten with 18 required sectionsdocs/mvp-scope.md— New filedocs/project-brief.md— New filedocs/conversation-handoff.md— New file (this document)docs/README.md— Updated indextests/docs/test_architecture.py— New automated validation suitetests/docs/__init__.py— New empty init
Downstream Dependencies
- FN-004: Backend Foundation — depends on the PostgreSQL domain model in Section 4
- FN-005: Frontend Foundation — depends on component boundaries in Section 3.1
- FN-006: Deployment Config — depends on Traefik routing model in Section 10
- FN-008: OpenCode POC — depends on spawn lifecycle in Section 8 and Docker runtime in Section 9
- FN-009: Config & Secrets — depends on storage layout in Section 11 and security in Section 13
- FN-010: code-server Spawn — depends on tool manifest in Section 7 and Docker runtime in Section 9
- FN-011: Git Provider — depends on Git provider abstraction in Section 5