thanhnvandClaude Opus 4.8
36a4812ef3
Standard production layout: the OKR app (was nested under AINative_OKR_CASAN5/) is now
the repository root. No more wrapper directory.
- Promote AINative_OKR_CASAN5/* -> repo root (backend/ frontend/ packages/ apps/
.specify/ docs/ infra/ nginx/ scripts/ + configs). Merge tool dirs: .gitea (kept the
active deploy ci.yml, added harness-ci.yml + runbooks), .claude (agents/commands +
launch.json), .github moved up.
- Remove redundant: 00_SUBMISSION_PACKAGE, scattered root notes (FPT_CASAN_Full.md,
tu-tuong-casan.md, casan-tu-sinh..., casan_harness_assessment.md, source-review...,
README_CASAN5_REFINED.md), casan-next-plans/ and optimize-docs/ (competition/planning
artifacts — roadmap + design history preserved in git log / commit messages).
- Update all references to the old layout:
- .gitea/workflows/{ci,harness-ci}.yml, .github/workflows/{ci,deploy}.yml:
working-directory .; drop AINative_OKR_CASAN5/ prefix; .specify/{tests,scripts}
-> packages/casan-harness/... (.specify/logs state kept)
- .claude/launch.json, .gitea/*-runbook.md: path prefixes
- CLAUDE.md, README.md: docs/input -> apps/okr/domain/input
- policy-bundle.yaml: 8 policy paths -> packages/casan-harness/...; manifest re-signed
- secrets-scan.sh: fixture excludes -> new package/domain paths.
Full gate from the new root: PASS=64 FAIL=0 SKIP=3.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
36 lines
1.6 KiB
Markdown
36 lines
1.6 KiB
Markdown
# Auto-Resolve Protocol (No-Pause Mode)
|
|
|
|
When any `[NEEDS CLARIFICATION]` marker or ambiguity is encountered at any step:
|
|
|
|
## Rule: Auto-Resolve with Optimal Assumption
|
|
|
|
1. **Identify** every `[NEEDS CLARIFICATION]` marker or ambiguous item.
|
|
2. **Evaluate** the best answer based on:
|
|
- Context from the SRS document
|
|
- Common engineering best practices for domain
|
|
- Conservative, safe defaults (prefer explicit over implicit, standard over custom)
|
|
- Existing patterns in the codebase (`src/modules/`)
|
|
3. **Choose** the optimal assumption and record it with rationale.
|
|
4. **Encode** the assumption directly into the document (replace marker with the resolved value).
|
|
5. **Report** every resolved item in the `## [AUTO-RESOLVED] Assumptions` section of the phase report.
|
|
|
|
## Auto-Resolved Assumptions Report Format
|
|
|
|
Every phase report MUST include:
|
|
|
|
```markdown
|
|
## [AUTO-RESOLVED] Assumptions
|
|
|
|
| # | ID | Original Question | Auto-Answer | Rationale | Confidence |
|
|
|---|----|-------------------|-------------|-----------|------------|
|
|
| 1 | TBC-01 | <original question text> | <chosen answer> | <why this was chosen> | High/Med/Low |
|
|
|
|
> ⚠ User Review Recommended: Items with Confidence=Low should be verified by the user at their convenience.
|
|
```
|
|
|
|
## Confidence Levels
|
|
|
|
- **High** — answer derived directly from SRS or existing codebase pattern, highly certain
|
|
- **Med** — answer based on best practice and domain knowledge, likely correct
|
|
- **Low** — answer is a reasonable guess; user should verify when convenient (pipeline continues)
|