refactor(structure): promote app to repo root + remove redundant workspace cruft
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>
This commit is contained in:
thanhnv
co-authored by
Claude Opus 4.8
Claude Opus 4.8
parent
7101af9fd4
commit
36a4812ef3
@@ -0,0 +1,92 @@
|
||||
<!--
|
||||
Sync Impact Report
|
||||
Version change: template -> 1.0.0
|
||||
Modified principles: placeholder principle 1 -> I. Requirement-First Definition; placeholder principle 2 -> II. Workflow and Role Traceability; placeholder principle 3 -> III. Test-First Delivery (Non-Negotiable); placeholder principle 4 -> IV. Reviewable Independent Increments; placeholder principle 5 -> V. Minimal Technical Commitment and Simplicity
|
||||
Added sections: Product Scope Constraints; Delivery Workflow and Quality Gates
|
||||
Removed sections: none
|
||||
Templates requiring updates:
|
||||
- ✅ .specify/templates/spec-template.md
|
||||
- ✅ .specify/templates/plan-template.md
|
||||
- ✅ .specify/templates/tasks-template.md
|
||||
- ⚠ pending none in .specify/templates/commands because that directory does not exist in this repository
|
||||
- ✅ README.md
|
||||
Follow-up TODOs: none
|
||||
-->
|
||||
|
||||
# OKR Web AI-SDLC Constitution
|
||||
|
||||
## Core Principles
|
||||
|
||||
### I. Requirement-First Definition
|
||||
Every feature artifact MUST begin from validated business intent, user outcomes, and workflow purpose.
|
||||
Specifications MUST describe what the system does and why the behavior matters before any implementation
|
||||
approach is chosen. If the input does not mandate a technical decision, the specification MUST leave that
|
||||
decision open and record the unresolved point explicitly instead of inventing detail.
|
||||
|
||||
Rationale: This project exists to transform customer requirements into reviewable delivery artifacts. Early
|
||||
technical commitments create rework and hide requirement gaps.
|
||||
|
||||
### II. Workflow and Role Traceability
|
||||
Each feature MUST trace back to a user role, a business workflow step, and an observable business outcome.
|
||||
Specifications, plans, and tasks MUST preserve that traceability so reviewers can verify why each unit of work
|
||||
exists. Scope that appears in mockups or examples but lacks defined behavior MUST be marked as excluded or
|
||||
clarification-needed until the requirement defines it.
|
||||
|
||||
Rationale: The OKR system depends on role-driven behavior across employee, manager, and admin workflows.
|
||||
Traceability prevents hidden assumptions and keeps delivery aligned with the stated process.
|
||||
|
||||
### III. Test-First Delivery (Non-Negotiable)
|
||||
Strict TDD is mandatory. For every behavior being implemented, tests MUST be written first, MUST be observed
|
||||
failing for the intended reason, and only then may production code be changed. Red-green-refactor is the
|
||||
required delivery cycle. No feature, fix, or refactor is complete unless automated tests prove the behavior.
|
||||
|
||||
Rationale: This repository uses AI-assisted delivery. Test-first execution is the control mechanism that keeps
|
||||
generated or assisted code aligned with the requirement and safe to evolve.
|
||||
|
||||
### IV. Reviewable Independent Increments
|
||||
User stories MUST be written and planned as independently testable slices that deliver visible value on their
|
||||
own. Each story MUST have acceptance scenarios, explicit success criteria, and a clear independent test path.
|
||||
Plans and tasks MUST allow reviewers to validate one increment without requiring the entire product to be done.
|
||||
|
||||
Rationale: Small, reviewable increments reduce ambiguity, surface defects earlier, and fit the project's staged
|
||||
AI-SDLC workflow.
|
||||
|
||||
### V. Minimal Technical Commitment and Simplicity
|
||||
Artifacts created before planning MUST avoid unnecessary architecture, tooling, or implementation detail.
|
||||
Technical choices MAY be documented only when the input explicitly mandates them or when deferring the choice
|
||||
would block requirement understanding. When a decision is necessary, the simplest option that satisfies the
|
||||
requirement and preserves future change MUST be preferred.
|
||||
|
||||
Rationale: Simplicity keeps the specification readable and keeps later planning honest about what is known
|
||||
versus what is still design work.
|
||||
|
||||
## Product Scope Constraints
|
||||
|
||||
This constitution governs an internal web-based OKR management system used in a workshop context. Current
|
||||
requirement scope includes authentication, objective creation, key result definition, manager approval,
|
||||
progress tracking, end-of-cycle evaluation, and dashboard visibility. The system MUST support company,
|
||||
department, and individual OKR management concepts where they are defined by the requirement. Production-scale
|
||||
operational concerns MUST not be assumed unless they are explicitly mandated by the input artifact for the
|
||||
feature being specified or planned.
|
||||
|
||||
## Delivery Workflow and Quality Gates
|
||||
|
||||
Work MUST proceed in the following order: requirement input, specification, clarification of gaps, plan,
|
||||
design artifacts, tasks, implementation, review, and test execution. A specification is not ready for planning
|
||||
unless it is clear, reviewable, technology-agnostic except for mandated constraints, and contains explicit
|
||||
clarification items for unresolved business rules. A plan is not ready for implementation unless its
|
||||
constitution check confirms strict TDD, independent story delivery, and traceability back to the specification.
|
||||
Tasks MUST list test work before implementation work for every user story. Reviews MUST reject artifacts that
|
||||
replace missing requirements with undocumented assumptions.
|
||||
|
||||
## Governance
|
||||
|
||||
This constitution overrides conflicting local habits and template defaults. Amendments MUST document the reason
|
||||
for change, the affected principles or sections, the semantic version bump rationale, and any downstream
|
||||
template updates required to keep the workflow aligned. Versioning follows semantic rules: MAJOR for breaking
|
||||
governance changes or removal of principles, MINOR for new principles or materially expanded obligations, and
|
||||
PATCH for clarifications that do not change expected behavior. Compliance review is mandatory during spec,
|
||||
plan, task, and implementation review. Any exception MUST be documented in the relevant artifact with explicit
|
||||
justification and reviewer acknowledgement.
|
||||
|
||||
**Version**: 1.0.0 | **Ratified**: 2026-04-05 | **Last Amended**: 2026-04-05
|
||||
@@ -0,0 +1,136 @@
|
||||
# 🔐 Security Policy
|
||||
## Project: AINATIVE_OKR_CLAUDE_GHCP
|
||||
|
||||
---
|
||||
|
||||
# 1. Purpose
|
||||
|
||||
Tài liệu này định nghĩa chính sách bảo mật cho AI System nhằm:
|
||||
|
||||
- Ngăn chặn prompt injection
|
||||
- Bảo vệ dữ liệu nhạy cảm (PII, secret)
|
||||
- Kiểm soát hành vi của LLM/Agent
|
||||
- Đảm bảo an toàn khi vận hành production
|
||||
|
||||
---
|
||||
|
||||
# 2. Scope
|
||||
|
||||
Áp dụng cho toàn bộ hệ thống:
|
||||
|
||||
- Prompt / LLM interaction
|
||||
- Agent workflow
|
||||
- Template generation (SpecKit)
|
||||
- Script automation
|
||||
- Logging & monitoring
|
||||
|
||||
---
|
||||
|
||||
# 3. Security Principles
|
||||
|
||||
- ✅ **Zero Trust Input**: Không tin bất kỳ input nào từ user
|
||||
- ✅ **Least Privilege**: Tool/Agent chỉ có quyền tối thiểu
|
||||
- ✅ **Defense in Depth**: nhiều lớp bảo vệ
|
||||
- ✅ **Auditability**: mọi hoạt động phải log được
|
||||
- ✅ **Fail Safe**: khi nghi ngờ → block hoặc require approval
|
||||
|
||||
---
|
||||
|
||||
# 4. Threat Model (OWASP LLM Top 10 based)
|
||||
|
||||
| Threat | Description |
|
||||
|------|-------------|
|
||||
| Prompt Injection | User cố override system |
|
||||
| Data Leakage | Lộ thông tin nội bộ |
|
||||
| Secret Exposure | Lộ API key / credential |
|
||||
| Unsafe Tool Call | Agent thực thi hành động nguy hiểm |
|
||||
| Hallucination Risk | Output sai nhưng có vẻ đúng |
|
||||
|
||||
---
|
||||
|
||||
# 5. Input Security Policy
|
||||
|
||||
## 5.1 Prompt Injection Protection
|
||||
|
||||
Block các pattern:
|
||||
|
||||
- "ignore previous instruction"
|
||||
- "bypass system"
|
||||
- "override policy"
|
||||
|
||||
### Action
|
||||
|
||||
| Level | Action |
|
||||
|------|--------|
|
||||
| High | Block |
|
||||
| Medium | Require Approval |
|
||||
| Low | Log |
|
||||
|
||||
---
|
||||
|
||||
## 5.2 PII Detection
|
||||
|
||||
Detect:
|
||||
|
||||
- Email
|
||||
- Phone number
|
||||
- Personal ID
|
||||
- Address
|
||||
|
||||
### Action
|
||||
|
||||
- Mask trước khi gửi LLM
|
||||
- Log sự kiện
|
||||
|
||||
---
|
||||
|
||||
## 5.3 Secret Detection
|
||||
|
||||
Detect:
|
||||
|
||||
- API Keys
|
||||
- Tokens
|
||||
- Password
|
||||
|
||||
### Action
|
||||
|
||||
- Block
|
||||
- Alert system
|
||||
- Không gửi vào LLM
|
||||
|
||||
---
|
||||
|
||||
# 6. Output Security Policy
|
||||
|
||||
## 6.1 Data Leakage Prevention
|
||||
|
||||
- Không output:
|
||||
- nội dung confidential
|
||||
- internal system prompt
|
||||
- hidden instruction
|
||||
|
||||
## 6.2 Output Filtering
|
||||
|
||||
| Type | Action |
|
||||
|------|--------|
|
||||
| PII | Mask |
|
||||
| Secret | Remove |
|
||||
| Unsafe content | Block |
|
||||
| Hallucination risk | Flag |
|
||||
|
||||
---
|
||||
|
||||
# 7. Tool Security Policy
|
||||
|
||||
## 7.1 Tool Access Control
|
||||
|
||||
| Tool | Permission |
|
||||
|------|----------|
|
||||
| Read File | Allow |
|
||||
| Write File | Restricted |
|
||||
| Delete File | Require Approval |
|
||||
| External API | Whitelist only |
|
||||
|
||||
---
|
||||
|
||||
## 7.2 Safe Tool Execution Flow
|
||||
Reference in New Issue
Block a user