61c5554c42
Commits merged: - docs(FN-019): complete Step 6 — documentation index, conversation handoff, project brief, and build config - test(FN-019): complete Step 4 — doc validation tests, project-brief.md, and fix mvp-scope placeholders - feat(FN-019): complete Step 3 — draft mvp-scope.md with milestones, dependency order, and open questions - docs(FN-019): fix auth callback flow, Python syntax, dev bypass clarity, add AccessProvider protocol and type stubs - feat(FN-019): complete Step 2 — draft enhanced architecture.md with all 18 required sections Files changed: docs/README.md | 11 +- docs/architecture.md | 1185 ++++++++++++++++++++++++++++++++++----- docs/conversation-handoff.md | 68 +++ docs/mvp-scope.md | 184 ++++++ docs/project-brief.md | 31 + package.json | 3 + tests/docs/__init__.py | 0 tests/docs/test_architecture.py | 120 ++++ 8 files changed, 1444 insertions(+), 158 deletions(-) Fusion-Task-Id: FN-019
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: RunFusion 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