Skip to content

Commit ceb4c56

Browse files
committed
repo: Update generated SCE config contracts and policy assets
Align generated OpenCode assets, CLI config handling, and current-state context with the latest SCE workflow contracts and config ownership rules. This bundles command-wrapper metadata, bash-policy runtime support, config-validation parity, and related context/plan updates in one repo-wide sync.
1 parent a83e317 commit ceb4c56

45 files changed

Lines changed: 972 additions & 147 deletions

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.
Lines changed: 10 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,9 @@
11
---
2-
description: "Create or update an SCE plan from a change request"
2+
description: "Use `sce-plan-authoring` to turn a change request into a scoped SCE plan"
33
agent: "Shared Context Plan"
4+
entry-skill: "sce-plan-authoring"
5+
skills:
6+
- "sce-plan-authoring"
47
---
58

69
Load and follow the `sce-plan-authoring` skill.
@@ -9,9 +12,9 @@ Input change request:
912
`$ARGUMENTS`
1013

1114
Behavior:
12-
- Keep this command as thin orchestration; delegate clarification/ambiguity handling and plan-shape contracts to `sce-plan-authoring`.
13-
- Ensure plan output follows one-task/one-atomic-commit slicing through `sce-plan-authoring` task-shape rules.
14-
- Write/update `context/plans/{plan_name}.md`.
15-
- Confirm plan creation with `{plan_name}` and exact path.
16-
- Return the full ordered task list.
17-
- Prompt user to start a new session to implement `T01` and provide `/next-task {plan_name} T01`.
15+
- Keep this command as thin orchestration; detailed clarification handling, plan-shape rules, and task-writing behavior stay owned by `sce-plan-authoring`.
16+
- Run `sce-plan-authoring` to resolve whether the input targets a new or existing plan, normalize goals/constraints/success criteria, and produce an implementation-ready task stack.
17+
- Preserve the clarification gate from `sce-plan-authoring`: if blockers, ambiguity, or missing acceptance criteria remain, stop and ask the focused user questions needed to finish the plan safely.
18+
- Require one-task/one-atomic-commit slicing through `sce-plan-authoring` before any task is considered ready for implementation.
19+
- When the plan is ready, write or update `context/plans/{plan_name}.md`, confirm the resolved `{plan_name}` and exact path, and return the ordered task list.
20+
- Stop after the planning handoff by providing the exact next-session command `/next-task {plan_name} T01`.

.opencode/command/commit.md

Lines changed: 8 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,9 @@
11
---
2-
description: "Propose atomic commit message(s) from staged changes"
2+
description: "Use `sce-atomic-commit` to propose atomic commit message(s) from staged changes"
33
agent: "Shared Context Code"
4+
entry-skill: "sce-atomic-commit"
5+
skills:
6+
- "sce-atomic-commit"
47
---
58

69
Load and follow the `sce-atomic-commit` skill.
@@ -11,15 +14,14 @@ Input:
1114
Behavior:
1215
- If arguments are empty, treat input as unstated and infer commit intent from staged changes only.
1316
- If arguments are provided, treat them as optional commit context to refine message proposals.
14-
- Before invoking `sce-atomic-commit`, explicitly prompt the user:
17+
- Keep this command as thin orchestration; staged-diff analysis, atomic split decisions, and message wording stay owned by `sce-atomic-commit`.
18+
- Before running `sce-atomic-commit`, explicitly stop and prompt the user:
1519

1620
"Please run `git add <files>` for all changes you want included in this commit.
1721
Atomic commits should only include intentionally staged changes.
1822
Confirm once staging is complete."
1923

2024
- After confirmation:
2125
- Classify staged diff scope (`context/`-only vs mixed `context/` + non-`context/`) and apply the context-guidance gate from `sce-atomic-commit`.
22-
- Delegate commit-message grammar, atomic split decisions, and split guidance to `sce-atomic-commit`.
23-
24-
- Do not create commits automatically.
25-
- Output only proposed commit message(s) and split guidance when needed.
26+
- Run `sce-atomic-commit` to produce commit-message proposals and any needed split guidance.
27+
- Do not create commits automatically; stop after returning proposed commit message(s) and split guidance when needed.

.opencode/command/drift-detect.md

Lines changed: 8 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,15 @@
11
---
2-
description: "Analyze and report drift between context and code"
2+
description: "Run `sce-drift-analyzer` to report context-code drift before edits"
33
agent: "Shared Context Drift"
4+
entry-skill: "sce-drift-analyzer"
5+
skills:
6+
- "sce-drift-analyzer"
47
---
58

69
Load and follow the `sce-drift-analyzer` skill.
710

811
Behavior:
9-
- Collect structured signals from `context/` and code.
10-
- Analyze mismatches between documented and implemented state.
11-
- Save findings to `context/tmp/drift-analysis-YYYY-MM-DD.md`.
12-
- Ask user whether to apply fixes or keep report-only output.
12+
- Keep this command as thin orchestration; drift detection logic, evidence gathering, and report structure stay owned by `sce-drift-analyzer`.
13+
- Run `sce-drift-analyzer` to compare `context/` against code truth, summarize mismatches, and write the drift report to `context/tmp/drift-analysis-YYYY-MM-DD.md`.
14+
- Stop after the analyzer reports findings; do not apply fixes from this command.
15+
- If the user wants repairs after reviewing the report, direct the next step to `/fix-drift` so update behavior stays owned by `sce-drift-fixer`.

.opencode/command/fix-drift.md

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -1,15 +1,15 @@
11
---
2-
description: "Resolve code-context drift using SCE rules"
2+
description: "Run `sce-drift-fixer` to repair context files from current code truth"
33
agent: "Shared Context Drift"
4+
entry-skill: "sce-drift-fixer"
5+
skills:
6+
- "sce-drift-fixer"
47
---
58

69
Load and follow the `sce-drift-fixer` skill.
710

8-
Audit the `context/` and ensure it correctly describes the system as implemented
9-
10-
- treat code as authoritative
11-
- summarize each discrepancy clearly
12-
- propose exact context updates
13-
- apply updates once the user confirms (or immediately if already authorized)
14-
15-
Make updates directly in `context/` and keep files concise, current-state oriented, and linked from `context/context-map.md` when relevant.
11+
Behavior:
12+
- Keep this command as thin orchestration; drift analysis, proposed repairs, and context edits stay owned by `sce-drift-fixer`.
13+
- Run `sce-drift-fixer` to audit `context/` against implemented code, treat code as authoritative, and summarize the exact context updates needed.
14+
- Preserve the fixer confirmation gate: apply updates only after explicit user confirmation unless the user already authorized fixes in the current session.
15+
- After approved fixes are applied, stop with the updated context state and any follow-up verification notes from `sce-drift-fixer`.

.opencode/command/handover.md

Lines changed: 9 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -1,19 +1,18 @@
11
---
2-
description: "Create a structured SCE handover of the current task"
2+
description: "Run `sce-handover-writer` to capture the current task for handoff"
33
agent: "Shared Context Code"
4+
entry-skill: "sce-handover-writer"
5+
skills:
6+
- "sce-handover-writer"
47
---
58

69
Load and follow the `sce-handover-writer` skill.
710

811
Input:
912
`$ARGUMENTS`
1013

11-
Create a new handover file in `context/handovers/` that captures:
12-
13-
- current task state
14-
- decisions made and rationale
15-
- open questions or blockers
16-
- next recommended step
17-
18-
Default naming should align with task execution handovers: `context/handovers/{plan_name}-{task_id}-{timestamp}.md`.
19-
If key details are missing, infer what you can from the current repo state and clearly label assumptions.
14+
Behavior:
15+
- Keep this command as thin orchestration; handover structure, naming, and content decisions stay owned by `sce-handover-writer`.
16+
- Run `sce-handover-writer` to gather current task state, decisions made and rationale, open questions or blockers, and the next recommended step.
17+
- Let `sce-handover-writer` create the handover in `context/handovers/`, using task-aligned naming such as `context/handovers/{plan_name}-{task_id}-{timestamp}.md` when the inputs support it.
18+
- If required details are missing, infer only from current repo state, label assumptions clearly, then stop after reporting the exact handover path.

.opencode/command/next-task.md

Lines changed: 16 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,12 @@
11
---
2-
description: "Review a plan and execute one SCE task from an approved plan"
2+
description: "Run `sce-plan-review` -> `sce-task-execution` -> `sce-context-sync` for one approved SCE task"
33
agent: "Shared Context Code"
4+
entry-skill: "sce-plan-review"
5+
skills:
6+
- "sce-plan-review"
7+
- "sce-task-execution"
8+
- "sce-context-sync"
9+
- "sce-validation"
410
---
511

612
Load and follow `sce-plan-review`, then `sce-task-execution`, then `sce-context-sync`.
@@ -13,12 +19,12 @@ Expected arguments:
1319
- task ID (`T0X`) (optional)
1420

1521
Behavior:
16-
- Run `sce-plan-review` first to resolve plan target/task and readiness.
17-
- Apply readiness confirmation gate from `sce-plan-review`:
18-
- auto-pass only when both plan + task ID are provided and review reports no blockers/ambiguity/missing acceptance criteria
19-
- otherwise resolve open points and ask user confirmation before execution
20-
- Run `sce-task-execution`; keep mandatory implementation stop, scoped implementation, checks/lints/build, and plan status updates skill-owned.
21-
- Run `sce-context-sync` as the required done gate.
22-
- 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.
23-
- If this is the final plan task, run `sce-validation`.
24-
- If more tasks remain, prompt a new session with `/next-task {plan_name} T0X`.
22+
- Keep this command as thin orchestration; skill-owned review, implementation, validation, and context-sync details stay in the referenced skills.
23+
- Run `sce-plan-review` first to resolve the plan target, choose the task, and report readiness.
24+
- Apply the readiness confirmation gate from `sce-plan-review` before implementation:
25+
- auto-pass only when both plan + task ID are provided and review reports no blockers, ambiguity, or missing acceptance criteria
26+
- otherwise resolve the open points and ask the user to confirm the task is ready before continuing
27+
- Run `sce-task-execution` next; keep the mandatory implementation stop, scoped edits, light checks/lints/build, and plan status updates skill-owned.
28+
- After implementation, run `sce-context-sync` as the required done gate and wait for user feedback.
29+
- If feedback requires in-scope fixes, apply the fixes, rerun light checks (and a light/fast build when applicable), then run `sce-context-sync` again.
30+
- If this was the final plan task, run `sce-validation`; otherwise stop after prompting a new session with `/next-task {plan_name} T0X`.

.opencode/command/validate.md

Lines changed: 8 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,9 @@
11
---
2-
description: "Run final validation and cleanup for an SCE plan"
2+
description: "Run `sce-validation` to finish an SCE plan with validation and cleanup"
33
agent: "Shared Context Code"
4+
entry-skill: "sce-validation"
5+
skills:
6+
- "sce-validation"
47
---
58

69
Load and follow the `sce-validation` skill.
@@ -9,6 +12,7 @@ Input:
912
`$ARGUMENTS`
1013

1114
Behavior:
12-
- Run full validation checks.
13-
- Capture evidence.
14-
- Report pass/fail and any residual risks.
15+
- Keep this command as thin orchestration; validation scope, command selection, cleanup, and evidence formatting stay owned by `sce-validation`.
16+
- Run `sce-validation` to execute the full validation phase for the targeted plan or change, including required checks, evidence capture, and cleanup expected by the skill.
17+
- Let `sce-validation` decide pass/fail status and record any residual risks or unmet criteria.
18+
- Stop after reporting the validation outcome and the location of any written validation evidence.
Lines changed: 47 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
{
2+
"schema_version": 1,
3+
"presets": [
4+
{
5+
"id": "forbid-git-all",
6+
"match": {
7+
"argv_prefixes": [["git"]]
8+
},
9+
"message": "This repository blocks `git` via SCE bash-tool policy. Use `jj` or the repo-approved alternative instead."
10+
},
11+
{
12+
"id": "forbid-git-commit",
13+
"match": {
14+
"argv_prefixes": [["git", "add"], ["git", "commit"], ["git", "push"]]
15+
},
16+
"message": "This repository blocks direct `git add`, `git commit`, and `git push`. Use `jj` instead."
17+
},
18+
{
19+
"id": "use-pnpm-over-npm",
20+
"match": {
21+
"argv_prefixes": [["npm"]]
22+
},
23+
"message": "This repository prefers `pnpm` over `npm`. Use `pnpm` instead."
24+
},
25+
{
26+
"id": "use-bun-over-npm",
27+
"match": {
28+
"argv_prefixes": [["npm"]]
29+
},
30+
"message": "This repository prefers `bun` over `npm`. Use `bun` instead."
31+
},
32+
{
33+
"id": "use-nix-flake-over-cargo",
34+
"match": {
35+
"argv_prefixes": [["cargo"]]
36+
},
37+
"message": "This repository prefers Nix flake entrypoints over direct `cargo` commands. Run Cargo through the documented `nix develop` / flake workflows instead."
38+
}
39+
],
40+
"mutually_exclusive": [["use-pnpm-over-npm", "use-bun-over-npm"]],
41+
"redundancy_warnings": [
42+
{
43+
"if_enabled": ["forbid-git-all", "forbid-git-commit"],
44+
"warning": "Preset 'forbid-git-commit' is redundant when 'forbid-git-all' is also enabled."
45+
}
46+
]
47+
}

0 commit comments

Comments
 (0)