docs: record full product-goal directive for /goal's 4000-char cap

[seonghobae]

Summary

• /goal's session-condition field is capped at 4000 characters; the user's full nine-section autonomous "PR review → fix → re-check GitHub Checks → merge → next development" loop directive is ~7900 characters and would lose specific constraints (exact library list, exact coverage thresholds, exact language mandates) if summarized to fit.
• Added docs/product-goal-directive.md, recording the directive verbatim under nine headed sections (execution loop, concurrent-work/root-cause fixes, research/standards traceability, UX/UI, architecture/naming/DB, implementation language/measurement, realistic verification/load/container testing, LLM/orchestration/embedding, reference libraries), plus a short /goal-sized pointer text that a future session can paste in instead of the full text.
• This follows this repo's own binding convention (docs/CWL-MASTER-CONTEXT.md §7: "Durable knowledge lives in the repo / Project / KG, NOT in an agent's private memory") — the directive now lives in the repo with no length limit, and /goal only needs to hold a pointer to it.
• Linked the new doc from AGENTS.md's read-first entry point, CLAUDE.md's "Read first" section, and docs/CWL-MASTER-CONTEXT.md §10 ("Current state") so any agent picks it up during normal onboarding, regardless of whether it was invoked via /goal, a Routine, or a fresh session.

Test plan

• PYTHONPATH=. pytest tests -q — 1879 passed, 1 skipped, 1 failed (test_materialized_bounded_include_is_resolvable_by_pip, pre-existing/unrelated: this session's pytest venv has no pip module installed, not caused by this doc-only change)
• tests/test_product_technical_gap_baseline.py (pins narrative pointers in docs/CWL-MASTER-CONTEXT.md §10) passes unchanged
• Confirmed no test asserts exact AGENTS.md prose before editing it

---

Generated by Claude Code

Summary by CodeRabbit

• 문서
  • 지속적인 PR 검토·수정·병합·개발 운영 절차를 설명하는 새 지침 문서를 추가했습니다.
  • 자동화된 운영 루프를 실행하거나 설정하기 전에 관련 지침을 확인하도록 안내를 보강했습니다.
  • 마스터 컨텍스트 문서에 운영 지침과 전체 문서 참조 방법을 기록했습니다.
  • 지침에는 실행 절차, 문서화, UX/UI, 아키텍처, 검증 및 테스트 기준이 포함됩니다.

[coderabbitai]

Warning

Review limit reached

Next included review available in 27 minutes.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 70f79fa5-54a1-4f58-b224-39fd75d5a7f2

📥 Commits

Reviewing files that changed from the base of the PR and between 6b18a15 and c035087.

📒 Files selected for processing (2)

• docs/doctoring/product-goal-directive.md
• docs/product-goal-directive.md

📝 Walkthrough

Walkthrough

docs/product-goal-directive.md에 자율 PR 운영 루프와 관련 개발 규칙을 추가했습니다. AGENTS.md, CLAUDE.md, docs/CWL-MASTER-CONTEXT.md는 이 문서를 전체 참조하도록 변경했습니다.

Changes

자율 운영 지침

Layer / File(s)	Summary
지침 범위와 실행 규칙 docs/product-goal-directive.md	실행 루프, 동시 작업, 문서 추적성, UX/UI, DDD, 데이터베이스 규칙을 정의했습니다.
구현 및 검증 규칙 docs/product-goal-directive.md	Rust 기반 계산, 테스트·문서화 범위, 부하·컨테이너 검증, LLM 오케스트레이션과 참조 라이브러리를 정의했습니다.
지침 참조 및 유지보수 AGENTS.md, CLAUDE.md, docs/CWL-MASTER-CONTEXT.md, docs/product-goal-directive.md	에이전트 지침과 마스터 컨텍스트에 전체 지침의 위치와 /goal 포인터 사용 규칙을 추가했습니다.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: 🔵 Low · up to 6b18a

The PR adds durable guidance that references multiple provider credentials without explicitly requiring gateway-only routing and privacy-preserving admission for every automated consumer. Existing central workflows limit immediate exposure, so the risk is bounded, but the security wording and one markdown lint issue should be addressed before or with merge.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	PR 제목은 /goal의 4000자 제한을 고려하여 전체 product-goal directive를 문서화하는 주요 변경을 정확하고 간결하게 설명합니다.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (4 skipped: 4 unsupported.)

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/contextualwisdomlab-product-goals-bfrgv3

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[seonghobae]

The required opencode-review check failed on the initial push (job 99233091685) with No APPROVED or CHANGES_REQUESTED from opencode-agent on the current head. That's the fail-closed gate in opencode-review.yml doing its job — it never checks out or executes PR content itself; it only requires that opencode-agent's privileged review dispatch (opencode-review-dispatch.yml, repository_dispatch-only) has already posted a current-head verdict.

Root cause found in pr-review-merge-scheduler.yml's own run for this PR (job 99233046308): PR #1429: skip: draft PR — scripts/ci/pr_review_merge_scheduler.py explicitly does not dispatch an OpenCode review for draft PRs. Since I opened this PR as a draft, the review that opencode-review waits for was never going to be dispatched, and the check would have stayed red indefinitely — not a defect in this PR's diff.

Fix: marked the PR ready for review, which fires the scheduler's ready_for_review trigger (new run 33302600510) and lets it dispatch the OpenCode review normally. Watching for that review and the recurring Required PR Review Merge Scheduler sweep (*/30 * * * *) to bring opencode-review current-head green.

---

Generated by Claude Code

[seonghobae]

The required noema-review check also failed on the initial push (job 99233046482), but this one is a real infra failure, not a draft-skip artifact — unrelated to this PR's diff (docs-only), and reproducible on any PR right now:

request_failed status=413 code=request_too_large
[contextual-orchestrator-sidecar] using live OpenRouter ZDR endpoint feed
[contextual-orchestrator-sidecar] error: sidecar exited before healthz (status 1); stderr: provider_discovery_failed provider=bytez code=http_status_500
review sidecar discovered no eligible models

Root cause, per scripts/ci/contextual_orchestrator_review_launcher.py: discover_all_models() isolates each provider's failure by design (Bytez's http_status_500 is correctly isolated and logged, not silently swallowed — that's the point of #1425/#1426, merged onto main just before this PR branched). But with Bytez down, the other four providers (NVIDIA NIM, NVIDIA NIM SUB, OpenAI; OpenRouter is evidence-only and never counts as servable) apparently contributed zero zero-priced (is_free) models this run, leaving the orchestrator/free pool empty and the sidecar failing closed as designed (docs/doctoring/noema-orchestrator-free-zdr.md: "an empty ZDR pool fails the required review; it never falls back to a non-ZDR provider").

I don't have the five provider secrets locally to reproduce discovery output outside CI, so I can't yet tell whether NVIDIA NIM/OpenAI having zero eligible models right now is itself a bug (e.g. in how is_free is derived for NIM's catalog) or a real, momentary gap in free-tier route availability compounding Bytez's outage. Re-ran the failed job once (rerun_failed_jobs on run 33302476439) to check whether this is transient — Bytez recovering alone would likely restore an eligible pool. If it fails again with the same shape, I'll dig into contextual_orchestrator/model_discovery.py's is_free derivation for the NVIDIA NIM and OpenAI providers in ContextualWisdomLab/contextual-orchestrator next, since that's outside what a re-run can fix.

---

Generated by Claude Code

[seonghobae]

Update on noema-review: the re-run failed again, but with a materially different signature — this time discovery reported zero provider errors (no provider_discovery_failed line at all; Bytez apparently succeeded) and still review sidecar discovered no eligible models. That rules out "Bytez 500 was the whole story" and confirms this isn't transient.

Root cause is already diagnosed and fixed upstream, just not merged yet: #1428 ("bump contextual-orchestrator vendored SHA to PR #919 head") — the pinned contextual-orchestrator SHA (5f2753ac) only joins free-cost Models.dev metadata for the opencode_zen provider, not for openai/nvidia_nim/nvidia_nim_sub, so when Bytez's own catalog doesn't currently surface a matching free chat model (500 or not), the whole orchestrator/free pool comes up empty and the sidecar fails closed by design. contextual-orchestrator#919 generalizes that join across all four models_dev_provider_id providers. This is also recorded independently in contextual-orchestrator's own docs/product-technical-gap-baseline.md (97b9772, "review-pipeline pin-bump verification") as confirmed org-wide — every open PR here, not just #1429.

This is where it stops being something I can fix from inside #1429: opencode-review/strix/noema-review are pull_request_target required checks that always run main's trusted copy of scripts/ci/contextual_orchestrator_review_sidecar.sh, never a PR's own changed copy. So porting the pin bump into #1429's branch would be a no-op for #1429 itself — it only takes effect once main carries it. And #1428 carries the fix but is itself blocked by the identical catch-22 (its own required checks run against main's still-old pin, so noema-review/opencode-review/strix fail on #1428's own head too, by design, until #1428 merges — which is exactly the trust boundary .github/CLAUDE.md documents and says not to widen).

I won't duplicate #1428's fix or attempt to route around its required checks. Watching both PRs; nothing further to push on #1429 for this specific failure until #1428 (or an equivalent base-branch fix) lands, at which point noema-review should go green on a re-run without any change to #1429's own diff.

---

Generated by Claude Code

[seonghobae]

Update on noema-review, current head c0350870: real progress, then a new, deeper layer.

The sidecar now correctly vendors the fixed pin (30c6d71680e659f25a0a433d4726ad0d437f9757, from #1430), and the earlier failure signature is gone — no provider_discovery_failed errors, no review sidecar discovered no eligible models. Discovery itself now succeeds (the free-pool-emptiness bug is fixed, confirming #1430 is a real fix).

But it still fails closed, one stage later:

request_failed status=413 code=request_too_large
using live OpenRouter ZDR endpoint feed
starting review sidecar on 127.0.0.1:18080
error: sidecar exited before healthz (status 1); stderr: discovery_diagnostics_complete
review sidecar preflight failed
omitted_unstructured_lines=4

review sidecar preflight failed is the launcher's ReviewPreflightError path — a non-empty free pool exists now, but every candidate route it tried failed the live 10-second chat-completions preflight. The sanitizer doesn't yet recognize this message shape (omitted_unstructured_lines=4), so the actual per-route rejection reasons aren't visible in this job's log the way discovery errors now are.

This is a distinct, deeper bug than the one #1430 just fixed, in the same shared central sidecar — not something in this PR's own docs-only diff, and not something I can usefully keep chasing layer-by-layer on this PR: there's already a fast-moving, concurrent effort actively iterating on exactly this sidecar right now (#1428/#1430 landed within the last ~40 minutes; the org's own hourly gap-baseline loop tracks this class of issue explicitly). I'll leave this one to that process rather than duplicate it, and keep #1429 watched — its own diff needs no further changes; it's waiting on shared CI infra outside its scope.

---

Generated by Claude Code