gitea-admin/CASAN
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
99 Commits 1 Branch 0 Tags
e891981b59f60a8544243385a2f820c649ac584f
Commit Graph
2 Commits
Author SHA1 Message Date
thanhnvandClaude Opus 4.8 e891981b59 feat(plan-01): Phase 4b — external callers to packages paths + registry (Task 1.7) 
Point the canonical entry points at the new package layout; the .specify compat facade
is retained as an intentional backward-compat layer (see below).

- .gitea/workflows/{ci,harness-ci}.yml: invoke packages/casan-harness/scripts/bash|tests
  (state paths .specify/logs kept). CI now runs on the new structure.
- infra/local-prod/docker-compose.yml: dashboard-server.py -> packages path (logs/alerts
  env stay under .specify state).
- scripts/casan-step.mjs + run-casan-pipeline.mjs: resolve the harness under
  packages/casan-harness, falling back to .specify so the adversarial/sourcegen sandboxes
  (which stage a .specify/ tree) keep working; requirement input prefers apps/okr/domain/input.
- project-registry.json: record the new layout (harness_root, state_root, governance_root,
  per-project domain_root) so Plan-06 can register a second app with its own domain.
  verify-harness-reuse.sh already resolves via CASAN_HARNESS_ROOT -> HARNESS_REUSE_VALID (3 projects).

Facade decision: the .specify/{scripts,tests,security,...} symlinks are KEPT as a
documented compat layer. A full hard cutover (removing them) still needs ~15 literal
`.specify/...` refs repointed (loop_common/evidence-pack/secrets-scan config+test paths,
run-casan-pipeline step scripts, and the signed policy-bundle.yaml path list which then
needs manifest regen + re-sign). That is a scoped follow-up; the physical separation
(code in packages/, domain in apps/, packages holds no domain data, single CASAN_* path
indirection) is complete and the full gate is green via BOTH entry paths: PASS=64 FAIL=0 SKIP=3.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-08 11:36:24 +09:00
thanhnvandClaude Sonnet 4.6 9892e82221 feat(wave5): CI/CD pipeline + Vault KMS + OKR deploy to port 80/3001 
Infrastructure (H3 CI gate, H5 KMS):
- Gitea Actions enabled (GITEA__actions__ENABLED=true)
- act_runner: Docker-outside-of-Docker for deploy job
- Vault Transit RSA-2048 signing keys (casan-audit-key, casan-policy-key)

Vault KMS scripts (H5 governance):
- .specify/scripts/bash/vault-kms.sh — sign/verify/pubkey/ensure-key
- .specify/scripts/bash/sign-audit-head.sh — sign audit chain via Vault
- Updated sign-policy-bundle.sh — Vault path + local fallback
- Updated security-gate.sh — KMS gate added (PASS=11 FAIL=0)

OKR app deployment (port 80/3001):
- Dockerfile.backend — node:22-slim (node:sqlite requires Node 22)
- Dockerfile.frontend — node:20-alpine build + nginx:alpine runtime
- nginx/nginx.conf — React SPA + /api/v1/* proxy to okr-backend:3001
- backend/entrypoint.sh — auto init DB on first run + seed
- .dockerignore

CI pipeline (.gitea/workflows/ci.yml):
- Job 1: Vitest frontend tests (H3)
- Job 2: CASAN security gate + Vault KMS signing (H4/H5)
- Job 3: Deploy OKR → port 80 (runs on push to main after tests pass)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-07-01 12:55:17 +09:00