ai-core-framework 0.1.0 → 0.3.0

package/{core/skills → skills}/planning-mark-ready/SKILL.md

@@ -18,7 +18,7 @@ args:
     format: "TICKET-XXX"
     description: "GROOMED ticket to verify against Definition of Ready"
 preconditions:
-  - ticket_exists: "project/tickets/${ticket_id}.json"
+  - ticket_exists: "docs/runtime/project/tickets/${ticket_id}.json"
   - ticket_status: GROOMED
   - has_estimate: true
   - has_acceptance_criteria: true
@@ -46,7 +46,7 @@ Manual only:
 
 ## 📋 Preconditions, STRICT
 
-1. Ticket exists in `project/tickets/`.
+1. Ticket exists in `docs/runtime/project/tickets/`.
 2. Ticket status is exactly `GROOMED`.
 3. Ticket has user story, acceptance criteria, estimate, technical approach, risks, and dependencies.
 4. Ticket estimate is one of `1, 2, 3, 5, 8`.
@@ -57,7 +57,7 @@ If any precondition fails, ABORT and keep the ticket in `GROOMED` or move to `BL
 
 ## 🔄 Execution Flow
 
-1. Load ticket JSON and `core/rules/07-definition-of-ready.md`.
+1. Load ticket JSON and `rules/07-definition-of-ready.md`.
 2. Validate INVEST criteria.
 3. Validate acceptance criteria are testable and include happy path, edge case, and error case.
 4. Validate estimation evidence from grooming.

package/{core/skills → skills}/planning-plan-refactor/SKILL.md

@@ -28,24 +28,24 @@ postconditions:
 
 ## 🎯 Purpose
 
-Plan large refactors without putting project-specific design into `core/`.
+Plan large refactors without putting project-specific design into framework source folders.
 
 ## 🔄 Execution Flow
 
-1. Load `config/project-structure.yaml`.
+1. Load `docs/config/project-structure.yaml`.
 2. Inspect affected code areas and docs.
 3. Identify current problem, target state, constraints, and risks.
 4. Determine whether ADR is required.
-5. Create `docs/runtime/refactor/<slug>-refactor-plan.md` from `core/templates/technical/refactor-plan-template.md`.
-6. Propose ticket breakdown for `project/tickets/`.
-7. Propose backlog entries for `project/backlog/backlog.json`.
+5. Create `docs/runtime/refactor/<slug>-refactor-plan.md` from `templates/technical/refactor-plan-template.md`.
+6. Propose ticket breakdown for `docs/runtime/project/tickets/`.
+7. Propose backlog entries for `docs/runtime/project/backlog/backlog.json`.
 8. Define testing, rollout, and rollback plan.
 9. HANDOFF to BA for ticket creation or Tech Lead for ADR.
 
 ## 🔒 Hard Rules
 
 - MUST NOT modify production code during planning.
-- MUST keep plan in `docs/runtime/refactor/`, not `core/`.
+- MUST keep plan in `docs/runtime/refactor/`, not framework source folders.
 - MUST create characterization test ticket before risky behavior-preserving refactors.
 - MUST require ADR for architectural decisions.
 - MUST split work into tickets of 8 points or less.

package/{core/skills → skills}/planning-plan-sprint/SKILL.md

@@ -35,7 +35,7 @@ postconditions:
 
 ## 🎯 Purpose
 
-Build a realistic sprint commitment. It selects only `READY` tickets, respects configured sprint capacity, checks dependencies, and writes the sprint plan to `project/sprints/`.
+Build a realistic sprint commitment. It selects only `READY` tickets, respects configured sprint capacity, checks dependencies, and writes the sprint plan to `docs/runtime/project/sprints/`.
 
 ## 🚦 Trigger
 
@@ -46,7 +46,7 @@ Manual at sprint planning:
 
 ## 📋 Preconditions, STRICT
 
-1. `config/project-config.yaml` exists.
+1. `docs/config/project-config.yaml` exists.
 2. `/validate-state` passes.
 3. At least one ticket has status `READY`.
 4. Sprint capacity is configured under `scrum.sprint_capacity_points`.
@@ -63,9 +63,9 @@ Manual at sprint planning:
 6. Select tickets until capacity is reached.
 7. Reserve capacity for bugs, review, QA, and operational work.
 8. Validate no selected ticket violates DoR.
-9. Write `project/sprints/SPRINT-XXX.json` with goal, dates, capacity, committed tickets, risks, and assumptions.
+9. Write `docs/runtime/project/sprints/SPRINT-XXX.json` with goal, dates, capacity, committed tickets, risks, and assumptions.
 10. Update selected tickets with `sprint_id`.
-11. Append planning metrics to `project/metrics/sprint-planning.jsonl`.
+11. Append planning metrics to `docs/runtime/project/metrics/sprint-planning.jsonl`.
 12. Output sprint goal, commitment, risks, and handoffs.
 
 ## 🔒 Hard Rules

package/{core/skills → skills}/planning-prioritize-backlog/SKILL.md

@@ -16,14 +16,14 @@ args:
     enum: [moscow, rice, manual]
     default: moscow
 preconditions:
-  - backlog_exists: "project/backlog/backlog.json"
+  - backlog_exists: "docs/runtime/project/backlog/backlog.json"
 postconditions:
   - backlog_order_updated: true
 ---
 
 # /prioritize-backlog
 
-> Updates backlog ranking in `project/backlog/backlog.json` using MoSCoW, RICE, dependencies, and stakeholder input.
+> Updates backlog ranking in `docs/runtime/project/backlog/backlog.json` using MoSCoW, RICE, dependencies, and stakeholder input.
 
 ## 🎯 Purpose
 

package/{core/skills → skills}/planning-write-plan/SKILL.md

@@ -42,7 +42,7 @@ Turn a groomed or ready ticket into a concrete execution plan before coding star
 
 ## Execution Flow
 
-1. Read `project/tickets/TICKET-XXX.json`.
+1. Read `docs/runtime/project/tickets/TICKET-XXX.json`.
 2. Read `spec_path` if present.
 3. Inspect relevant code/docs just enough to identify affected files and test strategy.
 4. Create `docs/project/plans/TICKET-XXX-<slug>-plan.md`.

package/{core/skills → skills}/project-detect-stack/SKILL.md

@@ -21,7 +21,7 @@ postconditions:
 
 ## 🎯 Purpose
 
-Populate or validate `config/project-config.yaml` from actual repository evidence instead of guesses.
+Populate or validate `docs/config/project-config.yaml` from actual repository evidence instead of guesses.
 
 ## 🚦 Trigger
 

package/{core/skills → skills}/project-discover-codebase/SKILL.md

@@ -37,13 +37,13 @@ Give AI agents shared context before implementation and review. The output helps
 
 ## 🔄 Execution Flow
 
-1. Load `config/project-config.yaml`.
+1. Load `docs/config/project-config.yaml`.
 2. Enumerate top-level directories and identify application, test, config, docs, scripts, and infra areas.
 3. Identify entry points, routes/controllers, domain modules, data access, jobs/workers, and shared libraries.
 4. Identify test layout and command coverage.
 5. Identify architecture docs and ADRs.
 6. Identify external integrations and environment assumptions.
-7. Produce `project/codebase-map.md` or update existing map with timestamp.
+7. Produce `docs/runtime/project/codebase-map.md` or update existing map with timestamp.
 8. List risks, missing docs, and recommended follow-up tickets.
 
 ## 🔒 Hard Rules

package/skills/project-setup-project/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: project-setup-project
+description: Use when the user asks to run /setup-project, initialize AI Core project state, review project config, sync platform configs, or prepare directories and logs for AI Core.
+command: /setup-project
+display_name: "Setup Project"
+version: 1.0.0
+status: READY
+owner_agent: scrum-master
+requires_agents:
+  - scrum-master
+consults_agents:
+  - tech-lead
+model_preference: sonnet
+args: []
+preconditions:
+  - ai_core_exists: true
+  - git_repo_exists: true
+postconditions:
+  - project_config_reviewed: true
+  - platform_configs_synced: true
+  - state_directories_created: true
+  - user_request_log_created: true
+  - hooks_install_recommended: true
+---
+
+# /setup-project
+
+> Initialize AI Core framework inside a project and prepare it for daily use.
+
+## 🎯 Purpose
+
+Make copied root-level framework folders operational in a real repository. This command checks repo structure, updates configuration, creates state directories, syncs platform instructions, and explains next steps.
+
+## 🚦 Trigger
+
+Manual after copying root-level framework folders into a project:
+
+- `/setup-project`
+- `bash scripts/setup-project.sh`
+
+## 📋 Preconditions, STRICT
+
+1. Repository has `.git/`.
+2. `README.md` exists.
+3. `templates/project/project-config.yaml` exists.
+4. `templates/project/project-structure.yaml` exists.
+5. User has permission to create `docs/config/`, `docs/runtime/project/`, `docs/project/`, `docs/runtime/`, `.claude/`, `.cursor/`, `.windsurfrules`, and `CLAUDE.md`.
+
+## 🔄 Execution Flow
+
+1. Confirm repo root and framework folder locations.
+2. Create `docs/config/` if missing.
+3. Copy `templates/project/project-config.yaml` to `docs/config/project-config.yaml` if missing.
+4. Copy `templates/project/project-structure.yaml` to `docs/config/project-structure.yaml` if missing.
+5. Ask for missing project fields or infer with `/detect-stack`.
+6. Create required `docs/runtime/project/` directories: tickets, backlog, bugs, sprints, releases, metrics, views, test-runs, verifications, incidents, prs.
+7. Create required docs namespaces: `docs/project/` for project/product requirements and `docs/runtime/` for operational AI Core documentation.
+8. Create `docs/runtime/project/backlog/backlog.json` and `docs/runtime/project/user-requests.jsonl` if missing.
+9. Run `bash scripts/setup-project.sh` when shell access is available, or perform steps 2-8 manually.
+10. Confirm `scripts/` contains the portable enforcement scripts.
+11. Install portable `.github/workflows/ai-core-governance.yml` if missing.
+12. Run `/sync-platforms` or `bash scripts/sync-platforms.sh`.
+13. Recommend installing hooks with `bash scripts/install-hooks.sh` if `.githooks/` exists.
+14. Run `/validate-state`.
+15. Output project readiness summary and first workflow suggestion.
+
+## 🔒 Hard Rules
+
+### RULE SP-001: Do not overwrite user config blindly
+If config values already exist, preserve them unless user confirms change.
+
+### RULE SP-002: Keep root-level framework folders canonical
+Generated `.claude/`, `.cursor/`, and `.windsurfrules` files are exports. Source changes belong in root-level framework folders.
+
+### RULE SP-003: No product code changes
+Setup modifies AI runtime/config files only: `docs/config/`, `docs/runtime/project/`, `docs/project/`, `docs/runtime/`, generated platform config, and optional docs scaffolding. It MUST NOT modify production source code.
+
+### RULE SP-004: State directories required
+A project is not ready until `docs/runtime/project/` contains directories for tickets, backlog, bugs, sprints, releases, metrics, views, test-runs, verifications, incidents, and prs.
+
+### RULE SP-004a: User request log required
+A project is not ready until `docs/runtime/project/user-requests.jsonl` exists. Every AI-handled user request **MUST** be logged there before substantive work begins.
+
+### RULE SP-005: Framework folders remain framework-only
+Project-specific state and config MUST NOT be written under framework source folders. Use `docs/runtime/project/` and `docs/config/`.
+
+### RULE SP-006: `scripts/` is canonical
+Portable enforcement scripts live under `scripts/`.
+
+## 📤 Outputs
+
+Success:
+
+- Config status
+- User request log status
+- Detected stack summary
+- Generated platform files
+- Hook install recommendation
+- Next command: `/analyze-requirements` or `/discover-codebase`
+
+Failure:
+
+- Missing root-level framework folders
+- Not a Git repository
+- Sync failure
+- Invalid config
+
+## 🔗 Related Commands
+
+- `/detect-stack`
+- `/discover-codebase`
+- `/sync-platforms`
+- `/validate-state`

package/{core/skills → skills}/qa-bug-status/SKILL.md

@@ -24,7 +24,7 @@ Give QA, Scrum Master, and Tech Lead a clear picture of defect health.
 
 ## 🔄 Execution Flow
 
-1. Load `project/bugs/*.json`.
+1. Load `docs/runtime/project/bugs/*.json`.
 2. Group bugs by severity and status.
 3. Identify stale bugs and missing owners.
 4. Identify release-blocking bugs.

package/{core/skills → skills}/qa-report-bug/SKILL.md

@@ -66,7 +66,7 @@ If not → prompt interactive collection.
 
 ### 2. Not duplicate
 Check existing open bugs for similar:
-- Grep bug titles in `project/bugs/*.json`
+- Grep bug titles in `docs/runtime/project/bugs/*.json`
 - If > 80% similarity → flag, ask if linking to existing
 
 ### 3. Has evidence (soft requirement)
@@ -125,7 +125,7 @@ If missing, still accept but flag in bug.
 │   BUG-NNN (separate sequence from TICKET-)               │
 ├──────────────────────────────────────────────────────────┤
 │ STEP 8: Create bug ticket                                │
-│   Path: project/bugs/BUG-NNN.json                 │
+│   Path: docs/runtime/project/bugs/BUG-NNN.json                 │
 │   Follow template: templates/qa/bug-report-template.md  │
 │   Initial status: NEW                                    │
 ├──────────────────────────────────────────────────────────┤
@@ -224,7 +224,7 @@ Missing env info = bug 50% harder to fix.
 Don't say "always" if not sure.
 
 ### RULE RB-009: Evidence preservation
-Screenshots, logs, HAR files → save to `project/bugs/evidence/BUG-NNN/`.
+Screenshots, logs, HAR files → save to `docs/runtime/project/bugs/evidence/BUG-NNN/`.
 
 Don't paste long logs in bug body → link to file.
 
@@ -304,8 +304,8 @@ Auto assess: Data integrity concern → SEV-1.
 Always (5/5 attempts)
 
 ### Evidence
-- Screenshot: `project/bugs/evidence/BUG-005/screenshot-1.png`
-- Network trace: `project/bugs/evidence/BUG-005/har.json`
+- Screenshot: `docs/runtime/project/bugs/evidence/BUG-005/screenshot-1.png`
+- Network trace: `docs/runtime/project/bugs/evidence/BUG-005/har.json`
 - Server log excerpt:
   ```
   2026-04-18T18:45:23Z ERROR handler/login.ts:42 
@@ -349,7 +349,7 @@ Likely: URL decoding treating + as space (classic `encodeURIComponent` vs `+` is
 
 ### Ticket File
 
-Created: `project/bugs/BUG-005.json`
+Created: `docs/runtime/project/bugs/BUG-005.json`
 
 ### Next Steps
 
@@ -405,7 +405,7 @@ Action: /triage-bug BUG-005
 - [ ] Executive team (if not resolved in 2h)
 
 ### Ticket File
-Created: `project/bugs/BUG-006.json`
+Created: `docs/runtime/project/bugs/BUG-006.json`
 
 ---
 HANDOFF → tech-lead + scrum-master (URGENT)
@@ -485,7 +485,7 @@ Developer cannot fix "broken" — needs specific scenario. Example of good bug:
 | Ambiguous severity | AI suggests, human confirms |
 | SEV-1 after hours | File + page on-call immediately |
 | Reporter gave bad info | Diplomatic pushback, guide to quality |
-| Evidence file too large | Store in core, link reference |
+| Evidence file too large | Store in the project evidence area, link reference |
 
 ## 🔗 Related Commands
 

package/{core/skills → skills}/qa-smoke-test/SKILL.md

@@ -79,7 +79,7 @@ curl -sf --max-time 10 "$STAGING_URL/health" || ABORT "Staging not responding"
 Check build version matches expected:
 ```bash
 deployed_commit=$(curl -s "$STAGING_URL/version" | jq -r .commit)
-expected_commit=$(cat project/tickets/${TICKET_ID}.json | jq -r .merge_info.merge_commit_sha)
+expected_commit=$(cat docs/runtime/project/tickets/${TICKET_ID}.json | jq -r .merge_info.merge_commit_sha)
 # Verify deployed >= expected
 ```
 
@@ -145,7 +145,7 @@ Required test accounts / test data exist. If not, setup before testing.
 │     → File separate regression bug (own ticket)          │
 ├──────────────────────────────────────────────────────────┤
 │ STEP 9: Generate report                                  │
-│   Save to: project/test-runs/TICKET-XXX-YYYYMMDD.md│
+│   Save to: docs/runtime/project/test-runs/TICKET-XXX-YYYYMMDD.md│
 ├──────────────────────────────────────────────────────────┤
 │ STEP 10: Handoff                                         │
 │   Pass → scrum-master (ready for release)                │
@@ -261,7 +261,7 @@ None 🎉
 Ticket state: QA → DONE ✅
 
 ### Test Run Record
-Saved to: `project/test-runs/TICKET-042-20260418.md`
+Saved to: `docs/runtime/project/test-runs/TICKET-042-20260418.md`
 
 ---
 HANDOFF → scrum-master

package/{core/skills → skills}/qa-verify-fix/SKILL.md

@@ -54,7 +54,7 @@ After developer claims the bug is fixed and PR is merged + deployed:
 
 ### 1. Bug exists + in correct state
 ```bash
-bug_status=$(cat project/bugs/${BUG_ID}.json | jq -r .status)
+bug_status=$(cat docs/runtime/project/bugs/${BUG_ID}.json | jq -r .status)
 [ "$bug_status" = "FIXED" ] || [ "$bug_status" = "READY_FOR_QA" ] || ABORT
 ```
 
@@ -141,7 +141,7 @@ Check linked PR is merged (not still open).
 │     → HANDOFF → developer                                │
 ├──────────────────────────────────────────────────────────┤
 │ STEP 9: Generate report                                  │
-│   Save to: project/verifications/BUG-XXX-YYYYMMDD.md│
+│   Save to: docs/runtime/project/verifications/BUG-XXX-YYYYMMDD.md│
 ├──────────────────────────────────────────────────────────┤
 │ STEP 10: Update bug state + notify                       │
 └──────────────────────────────────────────────────────────┘
@@ -267,7 +267,7 @@ Bug status: FIXED → VERIFIED
 - BUG-004 (email HTML rendering): Still open, separate fix
 
 ### Verification Record
-Saved to: `project/verifications/BUG-002-20260418.md`
+Saved to: `docs/runtime/project/verifications/BUG-002-20260418.md`
 
 ---
 HANDOFF → scrum-master

package/{core/skills → skills}/release-hotfix/SKILL.md

@@ -56,7 +56,7 @@ Manual:
 ## 🔄 Execution Flow
 
 1. Triage severity and impact.
-2. Create or link `BUG-NNN` in `project/bugs/`.
+2. Create or link `BUG-NNN` in `docs/runtime/project/bugs/`.
 3. Create hotfix ticket if needed with minimal AC and status `READY`.
 4. Create branch `hotfix/BUG-NNN-short-slug` or `hotfix/TICKET-NNN-short-slug` from production branch.
 5. Reproduce the issue and write a regression test if feasible.
@@ -69,7 +69,7 @@ Manual:
 12. QA verifies production or pre-prod depending on incident protocol.
 13. Back-merge hotfix into `develop`.
 14. Create follow-up ticket for full DoD, monitoring, and root cause analysis.
-15. Write incident summary in `project/releases/` or `project/incidents/`.
+15. Write incident summary in `docs/runtime/project/releases/` or `docs/runtime/project/incidents/`.
 
 ## 🔒 Hard Rules
 

package/{core/skills → skills}/release-release/SKILL.md

@@ -65,7 +65,7 @@ Manual:
 5. Confirm QA evidence exists for every included ticket.
 6. Check open bugs and known issues.
 7. Generate changelog with ticket IDs, PRs, bug fixes, migrations, and breaking changes.
-8. Create `project/releases/vX.Y.Z.json` from `core/templates/release/release-record-template.json` with scope, approvals, risks, deploy plan, rollback plan, and timestamps.
+8. Create `docs/runtime/project/releases/vX.Y.Z.json` from `templates/release/release-record-template.json` with scope, approvals, risks, deploy plan, rollback plan, and timestamps.
 9. Create or update release branch if configured.
 10. Tag release using `vX.Y.Z`.
 11. Trigger deployment or document manual deployment step.
@@ -93,7 +93,7 @@ Database migrations MUST include forward plan, rollback or mitigation, and backu
 Do not move an existing release tag. Create a new patch release instead.
 
 ### RULE REL-007: Release record schema required
-Every release record MUST satisfy `core/config/release.schema.json`. Missing approvals, rollback verification, QA evidence, security scan status, or known issue approval blocks release.
+Every release record MUST satisfy `docs/config/release.schema.json`. Missing approvals, rollback verification, QA evidence, security scan status, or known issue approval blocks release.
 
 ### RULE REL-008: Post-release smoke evidence
 If a release is marked `RELEASED` and `qa.post_release_smoke_required=true`, then `qa.post_release_smoke_passed=true` and the evidence path MUST be recorded.

package/{core/skills → skills}/release-rollback/SKILL.md

@@ -38,7 +38,7 @@ Restore service safely, preserve audit trail, and start follow-up remediation.
 4. Notify stakeholders and freeze related deploys.
 5. Execute documented rollback steps.
 6. Verify service health and core flows.
-7. Record rollback result in `project/releases/`.
+7. Record rollback result in `docs/runtime/project/releases/`.
 8. Create follow-up bug/ticket and incident notes.
 
 ## 🔒 Hard Rules

package/{core/skills → skills}/review-create-pr/SKILL.md

@@ -79,7 +79,7 @@ fi
 Extract TICKET-XXX from branch name, verify:
 ```bash
 TICKET_ID=$(echo "$current_branch" | grep -oE 'TICKET-[0-9]+')
-test -f "project/tickets/${TICKET_ID}.json" || ABORT
+test -f "docs/runtime/project/tickets/${TICKET_ID}.json" || ABORT
 ```
 
 ### 3. Ticket in IN_PROGRESS
@@ -203,7 +203,7 @@ fi
 │   - (Optional) Slack notification via webhook            │
 ├──────────────────────────────────────────────────────────┤
 │ STEP 10: Log metrics                                     │
-│   project/metrics/create-pr.jsonl                 │
+│   docs/runtime/project/metrics/create-pr.jsonl                 │
 └──────────────────────────────────────────────────────────┘
 ```
 

package/{core/skills → skills}/review-merge-pr/SKILL.md

@@ -205,7 +205,7 @@ If branch is `hotfix/*`:
 - Merge commit SHA
 - Strategy used
 
-Store in `project/audit-log.jsonl`.
+Store in `docs/runtime/project/audit-log.jsonl`.
 
 ### RULE MP-009: Rollback plan for risky merges
 If PR flagged as `high-risk` (auth changes, DB migration, payment):

package/{core/skills → skills}/using-ai-core/SKILL.md

@@ -29,7 +29,7 @@ guide /mark-ready TICKET-001
 next TICKET-001
 ```
 
-Do not ask users to type `bash core/scripts/ai-core.sh` or `AI_AGENT=...` during normal use. Those are internal tools for deterministic execution and CI.
+Do not ask users to type `bash scripts/ai-core.sh` or `AI_AGENT=...` during normal use. Those are internal tools for deterministic execution and CI.
 
 ## Agent Selection
 
@@ -42,12 +42,13 @@ If command metadata and user intent conflict, explain the conflict and stop.
 
 ## Source Of Truth
 
-- `project/` is machine-readable runtime state.
-- `docs/` is human-readable project documentation.
-- `config/` is project configuration.
-- `core/` is portable framework code.
+- `docs/runtime/project/` is machine-readable AI Core runtime state.
+- `docs/project/` is human-readable project and product documentation.
+- `docs/runtime/` also contains operational AI Core documentation.
+- `docs/config/` is project configuration.
+- Root-level framework folders are portable framework code.
 
-Do not move backlog, tickets, releases, bugs, sprints, or audit records into `docs/`. Generate human-readable summaries in `project/views/` and keep longer narrative docs in `docs/`.
+Keep backlog, tickets, releases, bugs, sprints, and audit records under `docs/runtime/project/`. Generate human-readable summaries in `docs/runtime/project/views/` and keep longer narrative project/product docs in `docs/project/`.
 
 ## Guided Report
 
@@ -69,4 +70,3 @@ Ask before running the next step. Do not continue automatically when the next co
 - No self-approval.
 - No DONE without fresh verification evidence.
 - No public API, setup, migration, architecture, or release-impacting change without the required docs evidence.
-

package/{core/skills → skills}/verification-before-done/SKILL.md

@@ -14,7 +14,7 @@ Before saying a workflow step is complete:
 1. Identify what proves the claim.
 2. Run or inspect the relevant verification.
 3. Read the result.
-4. Record evidence in `project/test-runs/`, `project/verifications/`, or the ticket.
+4. Record evidence in `docs/runtime/project/test-runs/`, `docs/runtime/project/verifications/`, or the ticket.
 5. Only then report completion.
 
 ## Required Evidence

package/{core/templates → templates}/ci/ai-core-governance.yml

@@ -3,20 +3,30 @@ name: AI Core Governance
 on:
   pull_request:
     paths:
-      - "core/**"
-      - "config/**"
-      - "project/**"
+      - "agents/**"
+      - "docs/config/**"
       - "docs/**"
+      - "hooks/**"
+      - "docs/runtime/project/**"
+      - "rules/**"
       - "scripts/**"
+      - "skills/**"
+      - "templates/**"
+      - "workflows/**"
       - ".github/workflows/ai-core-governance.yml"
   push:
     branches: [main, develop, "release/**"]
     paths:
-      - "core/**"
-      - "config/**"
-      - "project/**"
+      - "agents/**"
+      - "docs/config/**"
       - "docs/**"
+      - "hooks/**"
+      - "docs/runtime/project/**"
+      - "rules/**"
       - "scripts/**"
+      - "skills/**"
+      - "templates/**"
+      - "workflows/**"
       - ".github/workflows/ai-core-governance.yml"
 
 concurrency:
@@ -40,52 +50,52 @@ jobs:
           npm install -g ajv-cli@5
 
       - name: Make scripts executable
-        run: chmod +x core/scripts/*.sh
+        run: chmod +x scripts/*.sh
 
       - name: Validate ticket schemas
         run: |
           set -e
-          for ticket in project/tickets/*.json; do
+          for ticket in docs/runtime/project/tickets/*.json; do
             if [ ! -f "$ticket" ]; then continue; fi
-            ajv validate -s core/config/ticket.schema.json -d "$ticket"
+            ajv validate -s docs/config/ticket.schema.json -d "$ticket"
           done
 
       - name: Validate backlog schema
         run: |
-          if [ ! -f "project/backlog/backlog.json" ]; then
+          if [ ! -f "docs/runtime/project/backlog/backlog.json" ]; then
             echo "No backlog file, skipping"
             exit 0
           fi
-          ajv validate -s core/config/backlog.schema.json -d project/backlog/backlog.json
+          ajv validate -s docs/config/backlog.schema.json -d docs/runtime/project/backlog/backlog.json
 
       - name: Validate release schemas
         run: |
           set -e
-          for release in project/releases/*.json; do
+          for release in docs/runtime/project/releases/*.json; do
             if [ ! -f "$release" ]; then continue; fi
-            ajv validate -s core/config/release.schema.json -d "$release"
+            ajv validate -s docs/config/release.schema.json -d "$release"
           done
 
       - name: Validate state
-        run: bash core/scripts/validate-state.sh
+        run: bash scripts/validate-state.sh
 
       - name: Validate docs
         if: github.event_name == 'pull_request'
-        run: bash core/scripts/validate-docs.sh --base origin/${{ github.base_ref }}
+        run: bash scripts/validate-docs.sh --base origin/${{ github.base_ref }}
 
       - name: Validate permissions
-        run: bash core/scripts/validate-permissions.sh
+        run: bash scripts/validate-permissions.sh
 
       - name: Validate audit log
-        run: bash core/scripts/validate-audit-log.sh
+        run: bash scripts/validate-audit-log.sh
 
       - name: Generate views smoke test
-        run: bash core/scripts/generate-views.sh
+        run: bash scripts/generate-views.sh
 
       - name: Check state history immutability
         if: github.event_name == 'pull_request'
         run: |
-          CHANGED=$(git diff --name-only origin/${{ github.base_ref }}...HEAD -- 'project/tickets/*.json' || true)
+          CHANGED=$(git diff --name-only origin/${{ github.base_ref }}...HEAD -- 'docs/runtime/project/tickets/*.json' || true)
           if [ -z "$CHANGED" ]; then
             echo "No ticket changes"
             exit 0

package/{core/templates → templates}/pr/pull-request-template.md

@@ -11,7 +11,7 @@ Instructions for developer:
 
 <!-- 1-3 sentences: what does this PR do and why? -->
 
-**Ticket**: [TICKET-XXX](./project/tickets/TICKET-XXX.json) <!-- Auto-filled by /create-pr -->
+**Ticket**: [TICKET-XXX](./docs/runtime/project/tickets/TICKET-XXX.json) <!-- Auto-filled by /create-pr -->
 
 **Type**: <!-- feature | bugfix | hotfix | refactor | chore | docs -->
 

package/{core/templates → templates}/project/CODEOWNERS

@@ -1,9 +1,14 @@
 # AI Core governance ownership.
 #
 # Replace placeholder teams/users for each consuming repo.
-/core/ @tech-leads
-/config/ @scrum-masters @tech-leads
-/project/ @scrum-masters @tech-leads
+/agents/ @tech-leads
+/rules/ @tech-leads
+/scripts/ @tech-leads
+/skills/ @tech-leads
+/templates/ @tech-leads
+/workflows/ @tech-leads
+/docs/config/ @scrum-masters @tech-leads
+/docs/runtime/project/ @scrum-masters @tech-leads
 /docs/runtime/adr/ @tech-leads
 /docs/project/specs/ @product-owners @tech-leads
 /docs/project/plans/ @tech-leads

package/templates/project/docs-policy.json

@@ -0,0 +1,3 @@
+{
+  "extends": "docs/config/docs-policy.default.json"
+}