chore: initial hub repo structure

2026-07-09 22:08:26 +07:00
commit b31fe9d188
83 changed files with 7969 additions and 0 deletions
@@ -0,0 +1,52 @@
+# ADR 0001: Use a Hub Repository with App Submodules
+
+## Status
+
+Accepted
+
+## Context
+
+The project contains multiple independent application services that share one deployment surface: Docker Compose, Traefik routing, GitHub Actions workflows, and operational documentation.
+
+The services should be developed and versioned independently, while deployment infrastructure should remain centralized so production routing and compose manifests stay consistent.
+
+## Decision
+
+Use `asepharyana-hub` as the root hub repository.
+
+- Application code lives under `apps/<service>` as Git submodules.
+- Infrastructure lives in the root repo under `infra/`.
+- Documentation lives in the root repo under `docs/`.
+- CI/CD workflows live in the root repo under `.github/workflows/`.
+- Root tooling stays minimal: `package.json`, Prettier, ESLint, Makefile helpers, and deployment scripts.
+
+Current app submodules:
+
+| Service        | Path             | Remote                                  |
+| -------------- | ---------------- | --------------------------------------- |
+| Elysia API     | `apps/elysia`    | `asepharyana/asepharyana-hub-elysia`    |
+| React frontend | `apps/react`     | `asepharyana/asepharyana-hub-react`     |
+| Rust auth API  | `apps/rust-auth` | `asepharyana/asepharyana-hub-rust-auth` |
+| Scraper API    | `apps/scraper`   | `asepharyana/asepharyana-hub-scraper`   |
+
+## Consequences
+
+### Positive
+
+- Each app can evolve in its own repository.
+- The hub pins exact submodule revisions for reproducible deployments.
+- Deployment infrastructure remains centralized and easier to audit.
+- Root tooling stays lightweight and does not impose one build system on every service.
+
+### Negative
+
+- Developers must understand Git submodule workflows.
+- Updating a service requires updating the submodule pointer in the hub repo.
+- Cross-service changes require coordinating commits across multiple repositories.
+
+### Mitigations
+
+- Keep `.gitmodules` accurate and minimal.
+- Use `scripts/sync-submodules.sh` for local checkout consistency.
+- Document service-addition steps in `docs/add-new-app.md`.
+- Keep GitHub Actions responsible for Docker image builds, compose tag updates, and deployments.
@@ -0,0 +1,23 @@
+# Architecture Decision Records
+
+This directory contains Architecture Decision Records (ADRs).
+
+Each ADR documents an architectural decision, its context, and its consequences.
+
+## How to use
+
+```bash
+coder-workflow adr new "<decision title>"
+coder-workflow adr list
+coder-workflow adr status <id> --status accepted
+coder-workflow adr graph
+```
+
+## Status Definitions
+
+| Status     | Meaning                     |
+| ---------- | --------------------------- |
+| Proposed   | Under discussion            |
+| Accepted   | Agreed upon and implemented |
+| Deprecated | No longer recommended       |
+| Superseded | Replaced by a newer ADR     |