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>
93 lines
6.2 KiB
Markdown
93 lines
6.2 KiB
Markdown
---
|
||
description: Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync.
|
||
handoffs:
|
||
- label: Build Specification
|
||
agent: speckit.specify
|
||
prompt: Implement the feature specification based on the updated constitution. I want to build...
|
||
---
|
||
|
||
## Execution Logging & Phase Report (Constitution Art. XI & XII)
|
||
|
||
Before starting any work, write a **[START]** entry to `docs/output/output_logs/<feature-id>/logs/optional-constitution.log.md` with timestamp, agent name, model, input summary, and goal. Append **[PROCESSING]** entries at key milestones (e.g., "loaded constitution template", "collected N placeholder values", "filled M articles"). At completion, append **[END]** with status, output artifacts, metrics, and duration. On errors, append **[ISSUE]** with severity and description.
|
||
|
||
As your **final action**, write the phase report to `docs/output/output_logs/<feature-id>/reports/optional-constitution-report.md` following the Art. XII template (Summary, Inputs, Outputs, Key Decisions, Quality Assessment, Metrics, Next Step).
|
||
|
||
---
|
||
|
||
## User Input
|
||
|
||
```text
|
||
$ARGUMENTS
|
||
```
|
||
|
||
You **MUST** consider the user input before proceeding (if not empty).
|
||
|
||
## Outline
|
||
|
||
You are updating the project constitution at `.specify/memory/constitution.md`. This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.
|
||
|
||
**Note**: If `.specify/memory/constitution.md` does not exist yet, it should have been initialized from `.specify/templates/constitution-template.md` during project setup. If it's missing, copy the template first.
|
||
|
||
Follow this execution flow:
|
||
|
||
1. Load the existing constitution at `.specify/memory/constitution.md`.
|
||
- Identify every placeholder token of the form `[ALL_CAPS_IDENTIFIER]`.
|
||
**IMPORTANT**: The user might require less or more principles than the ones used in the template. If a number is specified, respect that - follow the general template. You will update the doc accordingly.
|
||
|
||
2. Collect/derive values for placeholders:
|
||
- If user input (conversation) supplies a value, use it.
|
||
- Otherwise infer from existing repo context (README, docs, prior constitution versions if embedded).
|
||
- For governance dates: `RATIFICATION_DATE` is the original adoption date (if unknown ask or mark TODO), `LAST_AMENDED_DATE` is today if changes are made, otherwise keep previous.
|
||
- `CONSTITUTION_VERSION` must increment according to semantic versioning rules:
|
||
- MAJOR: Backward incompatible governance/principle removals or redefinitions.
|
||
- MINOR: New principle/section added or materially expanded guidance.
|
||
- PATCH: Clarifications, wording, typo fixes, non-semantic refinements.
|
||
- If version bump type ambiguous, propose reasoning before finalizing.
|
||
|
||
3. Draft the updated constitution content:
|
||
- Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet—explicitly justify any left).
|
||
- Preserve heading hierarchy and comments can be removed once replaced unless they still add clarifying guidance.
|
||
- Ensure each Principle section: succinct name line, paragraph (or bullet list) capturing non‑negotiable rules, explicit rationale if not obvious.
|
||
- Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.
|
||
|
||
4. Consistency propagation checklist (convert prior checklist into active validations):
|
||
- Read `.specify/templates/plan-template.md` and ensure any "Constitution Check" or rules align with updated principles.
|
||
- Read `.specify/templates/spec-template.md` for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
|
||
- Read `.specify/templates/tasks-template.md` and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
|
||
- Read each command file in `.specify/templates/commands/*.md` (including this one) to verify no outdated references (agent-specific names like CLAUDE only) remain when generic guidance is required.
|
||
- Read any runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`, or agent-specific guidance files if present). Update references to principles changed.
|
||
|
||
5. Produce a Sync Impact Report (prepend as an HTML comment at top of the constitution file after update):
|
||
- Version change: old → new
|
||
- List of modified principles (old title → new title if renamed)
|
||
- Added sections
|
||
- Removed sections
|
||
- Templates requiring updates (✅ updated / ⚠ pending) with file paths
|
||
- Follow-up TODOs if any placeholders intentionally deferred.
|
||
|
||
6. Validation before final output:
|
||
- No remaining unexplained bracket tokens.
|
||
- Version line matches report.
|
||
- Dates ISO format YYYY-MM-DD.
|
||
- Principles are declarative, testable, and free of vague language ("should" → replace with MUST/SHOULD rationale where appropriate).
|
||
|
||
7. Write the completed constitution back to `.specify/memory/constitution.md` (overwrite).
|
||
|
||
8. Output a final summary to the user with:
|
||
- New version and bump rationale.
|
||
- Any files flagged for manual follow-up.
|
||
- Suggested commit message (e.g., `docs: amend constitution to vX.Y.Z (principle additions + governance update)`).
|
||
|
||
Formatting & Style Requirements:
|
||
|
||
- Use Markdown headings exactly as in the template (do not demote/promote levels).
|
||
- Wrap long rationale lines to keep readability (<100 chars ideally) but do not hard enforce with awkward breaks.
|
||
- Keep a single blank line between sections.
|
||
- Avoid trailing whitespace.
|
||
|
||
If the user supplies partial updates (e.g., only one principle revision), still perform validation and version decision steps.
|
||
|
||
If critical info missing (e.g., ratification date truly unknown), insert `TODO(<FIELD_NAME>): explanation` and include in the Sync Impact Report under deferred items.
|
||
|
||
Do not create a new template; always operate on the existing `.specify/memory/constitution.md` file.
|