starcoach-hackathon/zarinpal-analytics-deployment
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: define Qlockify adaptation contract

Browse Source
This commit is contained in:
Amirhossein Khalili
2026-08-20 19:07:31 +03:30
parent 3a854ad500
commit 21085c7405
4 changed files with 146 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/CROSS-REPOSITORY-PLAN-REVIEW.md
View File

@@ -31,19 +31,21 @@ The approved product, data, analytics, identity, API, UX, and operations specifi
2. Backend services: bounded demo authentication, metric query kernel, Redis/Asynq orchestration, details, exports, and provider integration.
3. Backend HTTP surface: OpenAPI conformance, middleware, auth/period/run/SSE/retry/detail/CSV endpoints, audit, and hardening.
4. Frontend: foundation and tokens, generated transport, shell/auth, dashboard sections, partial SSE states, detail/export workflows, responsive/accessibility/theme verification.
5. Deployment: resolve concrete server inputs, construct Compose/Nginx/CI/backup operations, integrate first-start ordering, verify locally, then perform the separately authorized server release.
5. Deployment: adapt Qlockify's Compose/Nginx/environment/manual-release/backup operations, integrate first-start ordering, verify locally with safe placeholders, then perform the separately authorized server release with real runtime values.
Backend provider work and frontend visual-system work can proceed in parallel after separate implementation authorization. Deployment scaffolding can also proceed in parallel once command/build contracts are stable; production bootstrap and cutover remain sequential gates.
## Remaining implementation inputs
## Deferred interface details (not planning blockers)
These are build-time choices, not unresolved product requirements:
- exact pinned OpenAPI generation/validation tools and repository command wrappers;
- exact frontend/backend build and health commands after their scaffolds exist (frontend history fallback is already restricted to non-API routes);
- server SSH identity, Git access method, DNS/ACME email, hardware limits, registry/cache policy, backup bucket settings, and alert destinations;
- exact backend/frontend command and environment-variable names after their scaffolds exist;
- the hosting path for human-readable API problem pages.
Server IP/DNS state, Git credentials, ACME email, ParsPack values, operator identity, and alert destinations are runtime inputs supplied when their operations are performed. They do not block implementation planning or local placeholder-based validation. Deployment uses no CI/CD pipeline, runner, or registry.
No secrets, raw dataset, generated database, credentials, certificates, backups, or runtime volumes may be committed.
## Authorization gate