Repository navigation
feat(deploy): vendor clearfolio + contextual-orchestrator as submodules (slice 60) - #280
Conversation
ScopeWeave now depends on two sibling services (산출물 뷰어 = clearfolio, AI 브리핑 = contextual-orchestrator). Bring them in as git submodules under vendor/ so the full stack builds/deploys together. - .gitmodules + vendor/clearfolio, vendor/contextual-orchestrator (pinned to their current main HEADs). - docker-compose.yml: clearfolio + orchestrator services added behind an optional `full` profile (build context = the submodules), wired to scopeweave via CLEARFOLIO_URL / ORCHESTRATOR_URL. Default profile still builds only scopeweave → `docker compose config/build` (CI evidence gate) and quick local runs are unchanged; server falls back to built-in mocks when the sidecar URLs are unset. - server-tests.yml: checkout submodules:false (the API/e2e suites don't need the vendored source; keeps CI fast and avoids submodule-auth needs). - .dockerignore: exclude vendor/ from the scopeweave image context. - README: submodule init + `docker compose --profile full up` instructions. Verified: podman build Dockerfile.server (vendor excluded) OK; default `compose config --services` = [scopeweave] only; `--profile full` = [scopeweave, clearfolio, orchestrator]; submodule status resolves both pinned commits. Note: full-stack build needs sidecar Dockerfiles — orchestrator via its PR #42, clearfolio Dockerfile is a follow-up. Stacked on #278. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018LMoqYsUY6usjNMBjvxCbU
Extend the multi-tenant Node backend into ITSM issue/Service-Request management on top of the WBS work-item tree. - Ingestion: POST /api/projects/:id/tasks:import maps an external ProjectSemanticObject payload (title, kind ∈ issue/requirement/feature/ service_request, source_segment_uids, confidence, edges) into work items and MERGES them into the tree without clobbering it (append new / update known). PAT- or JWT-authenticated, write-role gated. - Schema: work items now carry kind + source_segment_uids (evidence provenance) + evidence_confidence; new service_requests and service_request_events tables (2+ word snake_case columns) back the request layer. - Two-layer Service Request model: requester-facing ticket (catalog/intake → approval → fulfillment → closure, SLA) that on approval DECOMPOSES into linked work items on the performing team's board; their completion ROLLS UP to drive the request's fulfillment status (parent-child link + rollup). - Status lifecycle: real work-item state machine (open → in_progress → done, + cancel/reopen) via PATCH .../tasks/:taskId/status, plus the request state machine — no longer only progress-percent-derived. Legacy percent tasks are bridged into the machine. - Config: centralize all process.env reads into server/config.mjs; remove the insecure default JWT secret (fail-closed in production, ephemeral-random in dev). No scattered process.env remains outside config. - Tests: import mapping + merge, service-request decomposition + rollup, task & request status transitions, PAT auth, tenant isolation. Full suite green. - docs/papers: two CC-BY 4.0 reference papers (ITSM; requirements engineering). Claude-Session: https://claude.ai/code/session_01RTAMs4bpSZS77Xe3RQjv9P Co-authored-by: Seongho Bae <seonghobae@me.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
OpenCode Review Overview
Pull request overviewOpenCode reviewed the current-head bounded evidence and found no blocking issues. FindingsNo blocking findings. SummaryApproval sufficiency: bounded evidence supplied affirmative approval evidence for changed files, coverage/docstring posture, risk surfaces, and current-head verification; approval is not based merely on the absence of known blockers.
Changed-File Evidence Mapflowchart LR
PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
Evidence --> S1["Changed file (18 files)"]
S1 --> I1["repository behavior"]
I1 --> R1["Review risk: Changed file (18 files)"]
R1 --> V1["required checks"]
Evidence --> S2["Workflow: server-tests.yml"]
S2 --> I2["GitHub Actions review job"]
I2 --> R2["Review risk: Workflow: server-tests.yml"]
R2 --> V2["actionlint plus required checks"]
Evidence --> S3["Docs (5 files)"]
S3 --> I3["operator or user guidance"]
I3 --> R3["Review risk: Docs (5 files)"]
R3 --> V3["docs review"]
Evidence --> S4["Test (3 files)"]
S4 --> I4["regression suite"]
I4 --> R4["Review risk: Test (3 files)"]
R4 --> V4["targeted test run"]
|
![opencode-agent[bot]](https://avatars.githubusercontent.com/in/1549082?s=60&v=4){kind=small}
There was a problem hiding this comment.
Pull request overview
OpenCode reviewed the current-head bounded evidence and found no blocking issues.
Findings
No blocking findings.
Summary
Approval sufficiency: bounded evidence supplied affirmative approval evidence for changed files, coverage/docstring posture, risk surfaces, and current-head verification; approval is not based merely on the absence of known blockers.
Verification posture: CodeGraph evidence was initialized and bounded current-head evidence reviewed for changed-file evidence including .github/workflows/server-tests.yml, README.md, docker-compose.yml, docs/api.md, docs/deploy.md, and 15 more.
Linter/static: workflow/static review evidence is bounded by the current-head GitHub Checks gate and changed-file evidence.
TDD/regression: coverage execution evidence and focused changed hunks were reviewed from bounded-review-evidence.md.
Coverage: coverage execution evidence reports supported repository test suites passed.
Docstring coverage: coverage execution evidence reports configured repository docstring gates passed or docstring coverage was advisory.
DAG: CodeGraph/source-backed behavior map connects .github/workflows/server-tests.yml to the affected review, runtime, or workflow path and required checks.
PoC/execution: coverage-evidence job executed on the current head and reported PASS.
DDD/domain: workflow and repository-governance invariants were reviewed against changed files in bounded evidence.
CDD/context: CodeGraph evidence, changed-file history, and focused hunks were reviewed from bounded-review-evidence.md.
Similar issues: changed-file history evidence was reviewed for comparable local precedents.
Claim/concept check: bounded evidence, repository source, current-head workflow evidence, and, where numeric, scientific, statistical, or literature-backed claims are affected, original-paper/formula evidence and parameter-recovery expectations were used for claims.
Standards search: standards and external-source checks are delegated to configured OpenCode web_search/Context7/DeepWiki sources when applicable; no evidence-backed standards blocker is present in bounded evidence.
Compatibility/convention: changed workflow/script conventions, object naming, and reserved-word safety for schema/API/config/code surfaces were checked in bounded evidence.
Breaking-change/backcompat: deployment evidence and changed-file history were checked for backward-compatibility risk.
Performance: changed surfaces were checked for performance risk in bounded evidence.
Developer experience: changed automation, review, test, setup, and maintenance surfaces were checked for helpful or obstructive DX impact in bounded evidence.
User experience: connected user, operator, API, CLI, documentation, review-comment, status-check, rendering, and workflow-reader behavior was checked for contradictions against code, docs, and tests in bounded evidence.
Visual/DOM: Playwright visual, DOM locator, ARIA snapshot, console, and responsive evidence were checked when a web UI surface was present; for non-web surfaces, API/CLI/log/docs/workflow interaction evidence was reviewed instead.
Accessibility/i18n: accessibility, localization, and human-readable text surfaces were checked where UI, CLI, API message, docs, logs, or review text changed.
Supply-chain/license: dependency, package, model, container, and external-tool changes were checked in bounded evidence.
Packaging: package, build, test, lint, and security contracts were checked in bounded evidence.
Security/privacy: workflow-token, review-gate, and repository-automation security/privacy boundaries were checked in bounded evidence.
- Result: APPROVE
- Reason: PR is well-structured, passes all tests, and introduces no critical issues.
- Head SHA:
8a249b1dbd65fe104281a9361a689d2e6b9b3c22 - Workflow run: 29092446072
- Workflow attempt: 1
Changed-File Evidence Map
flowchart LR
PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
Evidence --> S1["Changed file (18 files)"]
S1 --> I1["repository behavior"]
I1 --> R1["Review risk: Changed file (18 files)"]
R1 --> V1["required checks"]
Evidence --> S2["Workflow: server-tests.yml"]
S2 --> I2["GitHub Actions review job"]
I2 --> R2["Review risk: Workflow: server-tests.yml"]
R2 --> V2["actionlint plus required checks"]
Evidence --> S3["Docs (5 files)"]
S3 --> I3["operator or user guidance"]
I3 --> R3["Review risk: Docs (5 files)"]
R3 --> V3["docs review"]
Evidence --> S4["Test (3 files)"]
S4 --> I4["regression suite"]
I4 --> R4["Review risk: Test (3 files)"]
R4 --> V4["targeted test run"]
1 participant
지시(‘submodule 반입’) 반영 — ScopeWeave가 의존하는 두 서비스를
vendor/서브모듈로 반입:full프로파일로 추가(빌드 컨텍스트=서브모듈),CLEARFOLIO_URL/ORCHESTRATOR_URL로 배선. 기본 프로파일은 scopeweave만 → CI 게이트·빠른 로컬 실행 불변(미설정 시 서버는 mock 폴백).submodules:false,.dockerignore에 vendor 제외, README에submodule update --init+--profile full안내.Verified
podman build(Dockerfile.server, vendor 제외) OK · 기본
compose config --services=[scopeweave] ·--profile full=[scopeweave,clearfolio,orchestrator] · submodule status 두 커밋 해석.🤖 Generated with Claude Code