Sce

.github/workflows/workflow-token-count.yml

@@ -0,0 +1,38 @@
+name: Workflow token count
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+    branches:
+      - main
+
+permissions:
+  contents: read
+
+jobs:
+  token-count:
+    name: Run workflow token count
+    runs-on: ubuntu-latest
+    timeout-minutes: 20
+    steps:
+      - name: Check out repository
+        uses: actions/checkout@v6
+
+      - name: Install Nix
+        uses: cachix/install-nix-action@v31
+
+      - name: Run workflow token-count app
+        run: nix run .#token-count-workflows
+
+      - name: Upload workflow token-count artifacts
+        uses: actions/upload-artifact@v4
+        with:
+          name: workflow-token-footprint
+          path: |
+            context/tmp/token-footprint/workflow-token-count-latest.json
+            context/tmp/token-footprint/workflow-token-count-latest.md
+            context/tmp/token-footprint/workflow-token-count-*.json
+            context/tmp/token-footprint/workflow-token-count-*.md
+          if-no-files-found: error

.opencode/agent/Shared Context Plan.md

@@ -71,6 +71,8 @@ Procedure
 Important behaviors
 - Keep context optimized for future AI sessions, not prose-heavy narration.
 - Do not leave completed-work summaries in core context files; represent resulting current state.
+- Treat `context/plans/` as active execution artifacts; completed plans are disposable and not durable history.
+- Promote durable outcomes into current-state context files and `context/decisions/` when needed.
 - Long-term quality is measured by code quality and context accuracy.
 
 Natural nudges to use

.opencode/command/change-to-plan.md

@@ -10,6 +10,7 @@ Input change request:
 
 Behavior:
 - Keep this command as thin orchestration; delegate clarification/ambiguity handling and plan-shape contracts to `sce-plan-authoring`.
+- Ensure plan output follows one-task/one-atomic-commit slicing through `sce-plan-authoring` task-shape rules.
 - Write/update `context/plans/{plan_name}.md`.
 - Confirm plan creation with `{plan_name}` and exact path.
 - Return the full ordered task list.

.opencode/command/commit.md

@@ -18,8 +18,8 @@ Behavior:
   Confirm once staging is complete."
 
 - After confirmation:
-  1. Inspect staged changes.
-  2. Delegate commit-message grammar, atomic split decisions, and split guidance to `sce-atomic-commit`.
+  - Classify staged diff scope (`context/`-only vs mixed `context/` + non-`context/`) and apply the context-guidance gate from `sce-atomic-commit`.
+  - Delegate commit-message grammar, atomic split decisions, and split guidance to `sce-atomic-commit`.
 
 - Do not create commits automatically.
 - Output only proposed commit message(s) and split guidance when needed.

.opencode/command/next-task.md

@@ -14,12 +14,11 @@ Expected arguments:
 
 Behavior:
 - Run `sce-plan-review` first to resolve plan target/task and readiness.
-- Confirmation gate before execution:
-  - if plan + task ID are provided and plan review reports no blockers/ambiguity/missing acceptance criteria, auto-pass readiness
-  - otherwise, resolve open points and ask the user to confirm the task is ready before continuing
-- After readiness passes, run `sce-task-execution` and enforce its mandatory implementation stop before any edits.
-- After user confirms that implementation stop, continue `sce-task-execution` for scoped implementation, checks/lints/build (as applicable), and plan task status updates.
-- Run `sce-context-sync` as a required done gate; keep `context/` aligned with code truth, including required shared-file verification and feature discoverability links.
+- Apply readiness confirmation gate from `sce-plan-review`:
+  - auto-pass only when both plan + task ID are provided and review reports no blockers/ambiguity/missing acceptance criteria
+  - otherwise resolve open points and ask user confirmation before execution
+- Run `sce-task-execution`; keep mandatory implementation stop, scoped implementation, checks/lints/build, and plan status updates skill-owned.
+- Run `sce-context-sync` as the required done gate.
 - Wait for user feedback; if in-scope fixes are requested, apply fixes, rerun light checks (and a light/fast build when applicable), then run `sce-context-sync` again.
 - If this is the final plan task, run `sce-validation`.
 - If more tasks remain, prompt a new session with `/next-task {plan_name} T0X`.

.opencode/skills/sce-atomic-commit/SKILL.md

@@ -72,6 +72,12 @@ Default split order:
 3. tests
 4. docs
 
+## Context-file guidance gating
+
+- Check staged diff scope before proposing commit messaging guidance.
+- If staged changes are context-only (`context/**`), context-file-focused guidance is allowed.
+- If staged changes are mixed (`context/**` + non-`context/**`), avoid default context-file commit reminders and prioritize guidance that reflects the full staged scope.
+
 ## Anti-patterns
 
 - vague subjects ("cleanup", "updates")

.opencode/skills/sce-context-sync/SKILL.md

@@ -8,15 +8,15 @@ compatibility: opencode
 - Context is durable AI memory and must reflect current-state truth.
 - If context and code diverge, code is source of truth.
 
-## Mandatory sync pass (always check all)
-For every completed implementation task, explicitly review and update these files when relevant:
+## Mandatory sync pass (important-change gated)
+For every completed implementation task, run a sync pass over these shared files:
 - `context/overview.md`
 - `context/architecture.md`
 - `context/glossary.md`
 - `context/patterns.md`
 - `context/context-map.md`
 
-Do not skip `overview`, `architecture`, or `glossary` by default. If no edit is needed, verify they still match current code behavior.
+Do not default to editing root context files on every task. First classify whether the task is an important change; then edit or verify accordingly.
 
 ## Root context significance gating
 - Treat root context edits as required when a task introduces or changes cross-cutting behavior, repository-wide policy/contracts, architecture boundaries, or canonical terminology.

.opencode/skills/sce-plan-authoring/SKILL.md

@@ -44,6 +44,25 @@ For each task include:
 - Done when
 - Verification notes (commands or checks)
 
+## Atomic task slicing contract (required)
+- Author each executable task as one atomic commit unit by default.
+- Every task must be scoped so one contributor can complete it and land it as one coherent commit without bundling unrelated changes.
+- If a candidate task would require multiple independent commits (for example: refactor + behavior change + docs), split it into separate sequential tasks before finalizing the plan.
+- Keep broad wrappers (`polish`, `finalize`, `misc updates`) out of executable tasks; convert them into specific outcomes with concrete acceptance checks.
+
+Use this quick atomicity check before accepting each task:
+- `single_intent`: task delivers one primary outcome
+- `single_area`: task touch scope is narrow and related
+- `single_verification`: done checks validate one coherent change set
+
+Example compliant skeleton:
+- [ ] T0X: `[single intent title]` (status:todo)
+  - Task ID: T0X
+  - Goal: `[one outcome]`
+  - Boundaries (in/out of scope): `[tight scope]`
+  - Done when: `[clear acceptance for one coherent change]`
+  - Verification notes (commands or checks): `[targeted checks for this change]`
+
 Use checkbox lines for machine-friendly progress tracking:
 - `- [ ] T01: ... (status:todo)`
 

.opencode/skills/sce-plan-review/SKILL.md

@@ -28,6 +28,8 @@ compatibility: opencode
 ## Rules
 - Do not auto-mark tasks complete during review.
 - Keep continuation state in the plan markdown itself.
+- Treat `context/plans/` as active execution artifacts; completed plans are disposable and not a durable context source.
+- If durable history is needed, record it in current-state context files and/or `context/decisions/` instead of completed plan files.
 - Keep implementation blocked until decision alignment on unclear points.
 - If plan context is stale or partial, continue with code truth and flag context updates.
 

.opencode/skills/sce-task-execution/SKILL.md

@@ -25,8 +25,9 @@ compatibility: opencode
 3) Stop and ask: "Continue with implementation now?" (yes/no).
 4) Implement minimal in-scope changes.
 5) Run light task-level tests/checks and lints first, and run a build when the build is light/fast (targeted over full-suite unless requested), then capture evidence.
-6) Keep session-only scraps in `context/tmp/`.
-7) Update task status in `context/plans/{plan_id}.md`.
+6) Record whether the implementation is an important change for context sync (root-edit required) or verify-only (no root edits expected).
+7) Keep session-only scraps in `context/tmp/`.
+8) Update task status in `context/plans/{plan_id}.md`.
 
 ## Scope expansion rule
 - If out-of-scope edits are needed, stop and ask for approval.

README.md

@@ -18,6 +18,29 @@ boundaries.
 
 Built by [CroCoder](https://www.crocoder.dev/)
 
+## Workflow token counting
+
+Static workflow token-footprint reports are produced by the T06 script at
+`evals/token-count-workflows.ts` using the canonical manifest
+`context/sce/workflow-token-footprint-manifest.json`.
+
+```bash
+cd evals
+bun run token-count-workflows
+```
+
+Optional inputs:
+
+```bash
+bun run token-count-workflows --run-id local-test
+bun run token-count-workflows --baseline ../context/tmp/token-footprint/workflow-token-count-latest.json
+```
+
+Outputs are written to `context/tmp/token-footprint/` as:
+- `workflow-token-count-latest.json`
+- `workflow-token-count-latest.md`
+- `workflow-token-count-<run_id>.json` (when `--run-id` is provided)
+
 ## Dev shell agnix tooling
 
 This repository exposes `agnix` and `agnix-lsp` through `nix develop` using a Nix-first shell with Rust toolchain support.

config/.claude/agents/shared-context-plan.md

@@ -50,6 +50,8 @@ Procedure
 Important behaviors
 - Keep context optimized for future AI sessions, not prose-heavy narration.
 - Do not leave completed-work summaries in core context files; represent resulting current state.
+- Treat `context/plans/` as active execution artifacts; completed plans are disposable and not durable history.
+- Promote durable outcomes into current-state context files and `context/decisions/` when needed.
 - Long-term quality is measured by code quality and context accuracy.
 
 Natural nudges to use

config/.claude/commands/change-to-plan.md

@@ -10,6 +10,7 @@ Input change request:
 
 Behavior:
 - Keep this command as thin orchestration; delegate clarification/ambiguity handling and plan-shape contracts to `sce-plan-authoring`.
+- Ensure plan output follows one-task/one-atomic-commit slicing through `sce-plan-authoring` task-shape rules.
 - Write/update `context/plans/{plan_name}.md`.
 - Confirm plan creation with `{plan_name}` and exact path.
 - Return the full ordered task list.

config/.claude/commands/commit.md

@@ -18,8 +18,8 @@ Behavior:
   Confirm once staging is complete."
 
 - After confirmation:
-  1. Inspect staged changes.
-  2. Delegate commit-message grammar, atomic split decisions, and split guidance to `sce-atomic-commit`.
+  - Classify staged diff scope (`context/`-only vs mixed `context/` + non-`context/`) and apply the context-guidance gate from `sce-atomic-commit`.
+  - Delegate commit-message grammar, atomic split decisions, and split guidance to `sce-atomic-commit`.
 
 - Do not create commits automatically.
 - Output only proposed commit message(s) and split guidance when needed.

config/.claude/commands/next-task.md

@@ -14,12 +14,11 @@ Expected arguments:
 
 Behavior:
 - Run `sce-plan-review` first to resolve plan target/task and readiness.
-- Confirmation gate before execution:
-  - if plan + task ID are provided and plan review reports no blockers/ambiguity/missing acceptance criteria, auto-pass readiness
-  - otherwise, resolve open points and ask the user to confirm the task is ready before continuing
-- After readiness passes, run `sce-task-execution` and enforce its mandatory implementation stop before any edits.
-- After user confirms that implementation stop, continue `sce-task-execution` for scoped implementation, checks/lints/build (as applicable), and plan task status updates.
-- Run `sce-context-sync` as a required done gate; keep `context/` aligned with code truth, including required shared-file verification and feature discoverability links.
+- Apply readiness confirmation gate from `sce-plan-review`:
+  - auto-pass only when both plan + task ID are provided and review reports no blockers/ambiguity/missing acceptance criteria
+  - otherwise resolve open points and ask user confirmation before execution
+- Run `sce-task-execution`; keep mandatory implementation stop, scoped implementation, checks/lints/build, and plan status updates skill-owned.
+- Run `sce-context-sync` as the required done gate.
 - Wait for user feedback; if in-scope fixes are requested, apply fixes, rerun light checks (and a light/fast build when applicable), then run `sce-context-sync` again.
 - If this is the final plan task, run `sce-validation`.
 - If more tasks remain, prompt a new session with `/next-task {plan_name} T0X`.

config/.claude/skills/sce-atomic-commit/SKILL.md

@@ -72,6 +72,12 @@ Default split order:
 3. tests
 4. docs
 
+## Context-file guidance gating
+
+- Check staged diff scope before proposing commit messaging guidance.
+- If staged changes are context-only (`context/**`), context-file-focused guidance is allowed.
+- If staged changes are mixed (`context/**` + non-`context/**`), avoid default context-file commit reminders and prioritize guidance that reflects the full staged scope.
+
 ## Anti-patterns
 
 - vague subjects ("cleanup", "updates")

config/.claude/skills/sce-context-sync/SKILL.md

@@ -8,15 +8,15 @@ compatibility: claude
 - Context is durable AI memory and must reflect current-state truth.
 - If context and code diverge, code is source of truth.
 
-## Mandatory sync pass (always check all)
-For every completed implementation task, explicitly review and update these files when relevant:
+## Mandatory sync pass (important-change gated)
+For every completed implementation task, run a sync pass over these shared files:
 - `context/overview.md`
 - `context/architecture.md`
 - `context/glossary.md`
 - `context/patterns.md`
 - `context/context-map.md`
 
-Do not skip `overview`, `architecture`, or `glossary` by default. If no edit is needed, verify they still match current code behavior.
+Do not default to editing root context files on every task. First classify whether the task is an important change; then edit or verify accordingly.
 
 ## Root context significance gating
 - Treat root context edits as required when a task introduces or changes cross-cutting behavior, repository-wide policy/contracts, architecture boundaries, or canonical terminology.

config/.claude/skills/sce-plan-authoring/SKILL.md

@@ -44,6 +44,25 @@ For each task include:
 - Done when
 - Verification notes (commands or checks)
 
+## Atomic task slicing contract (required)
+- Author each executable task as one atomic commit unit by default.
+- Every task must be scoped so one contributor can complete it and land it as one coherent commit without bundling unrelated changes.
+- If a candidate task would require multiple independent commits (for example: refactor + behavior change + docs), split it into separate sequential tasks before finalizing the plan.
+- Keep broad wrappers (`polish`, `finalize`, `misc updates`) out of executable tasks; convert them into specific outcomes with concrete acceptance checks.
+
+Use this quick atomicity check before accepting each task:
+- `single_intent`: task delivers one primary outcome
+- `single_area`: task touch scope is narrow and related
+- `single_verification`: done checks validate one coherent change set
+
+Example compliant skeleton:
+- [ ] T0X: `[single intent title]` (status:todo)
+  - Task ID: T0X
+  - Goal: `[one outcome]`
+  - Boundaries (in/out of scope): `[tight scope]`
+  - Done when: `[clear acceptance for one coherent change]`
+  - Verification notes (commands or checks): `[targeted checks for this change]`
+
 Use checkbox lines for machine-friendly progress tracking:
 - `- [ ] T01: ... (status:todo)`
 

config/.claude/skills/sce-plan-review/SKILL.md

@@ -28,6 +28,8 @@ compatibility: claude
 ## Rules
 - Do not auto-mark tasks complete during review.
 - Keep continuation state in the plan markdown itself.
+- Treat `context/plans/` as active execution artifacts; completed plans are disposable and not a durable context source.
+- If durable history is needed, record it in current-state context files and/or `context/decisions/` instead of completed plan files.
 - Keep implementation blocked until decision alignment on unclear points.
 - If plan context is stale or partial, continue with code truth and flag context updates.
 

config/.claude/skills/sce-task-execution/SKILL.md

@@ -25,8 +25,9 @@ compatibility: claude
 3) Stop and ask: "Continue with implementation now?" (yes/no).
 4) Implement minimal in-scope changes.
 5) Run light task-level tests/checks and lints first, and run a build when the build is light/fast (targeted over full-suite unless requested), then capture evidence.
-6) Keep session-only scraps in `context/tmp/`.
-7) Update task status in `context/plans/{plan_id}.md`.
+6) Record whether the implementation is an important change for context sync (root-edit required) or verify-only (no root edits expected).
+7) Keep session-only scraps in `context/tmp/`.
+8) Update task status in `context/plans/{plan_id}.md`.
 
 ## Scope expansion rule
 - If out-of-scope edits are needed, stop and ask for approval.

config/.opencode/agent/Shared Context Plan.md

@@ -71,6 +71,8 @@ Procedure
 Important behaviors
 - Keep context optimized for future AI sessions, not prose-heavy narration.
 - Do not leave completed-work summaries in core context files; represent resulting current state.
+- Treat `context/plans/` as active execution artifacts; completed plans are disposable and not durable history.
+- Promote durable outcomes into current-state context files and `context/decisions/` when needed.
 - Long-term quality is measured by code quality and context accuracy.
 
 Natural nudges to use

config/.opencode/command/change-to-plan.md

@@ -10,6 +10,7 @@ Input change request:
 
 Behavior:
 - Keep this command as thin orchestration; delegate clarification/ambiguity handling and plan-shape contracts to `sce-plan-authoring`.
+- Ensure plan output follows one-task/one-atomic-commit slicing through `sce-plan-authoring` task-shape rules.
 - Write/update `context/plans/{plan_name}.md`.
 - Confirm plan creation with `{plan_name}` and exact path.
 - Return the full ordered task list.

config/.opencode/command/commit.md

@@ -18,8 +18,8 @@ Behavior:
   Confirm once staging is complete."
 
 - After confirmation:
-  1. Inspect staged changes.
-  2. Delegate commit-message grammar, atomic split decisions, and split guidance to `sce-atomic-commit`.
+  - Classify staged diff scope (`context/`-only vs mixed `context/` + non-`context/`) and apply the context-guidance gate from `sce-atomic-commit`.
+  - Delegate commit-message grammar, atomic split decisions, and split guidance to `sce-atomic-commit`.
 
 - Do not create commits automatically.
 - Output only proposed commit message(s) and split guidance when needed.

config/.opencode/command/next-task.md

@@ -14,12 +14,11 @@ Expected arguments:
 
 Behavior:
 - Run `sce-plan-review` first to resolve plan target/task and readiness.
-- Confirmation gate before execution:
-  - if plan + task ID are provided and plan review reports no blockers/ambiguity/missing acceptance criteria, auto-pass readiness
-  - otherwise, resolve open points and ask the user to confirm the task is ready before continuing
-- After readiness passes, run `sce-task-execution` and enforce its mandatory implementation stop before any edits.
-- After user confirms that implementation stop, continue `sce-task-execution` for scoped implementation, checks/lints/build (as applicable), and plan task status updates.
-- Run `sce-context-sync` as a required done gate; keep `context/` aligned with code truth, including required shared-file verification and feature discoverability links.
+- Apply readiness confirmation gate from `sce-plan-review`:
+  - auto-pass only when both plan + task ID are provided and review reports no blockers/ambiguity/missing acceptance criteria
+  - otherwise resolve open points and ask user confirmation before execution
+- Run `sce-task-execution`; keep mandatory implementation stop, scoped implementation, checks/lints/build, and plan status updates skill-owned.
+- Run `sce-context-sync` as the required done gate.
 - Wait for user feedback; if in-scope fixes are requested, apply fixes, rerun light checks (and a light/fast build when applicable), then run `sce-context-sync` again.
 - If this is the final plan task, run `sce-validation`.
 - If more tasks remain, prompt a new session with `/next-task {plan_name} T0X`.