trackops 2.0.3 → 2.0.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -21
- package/README.md +695 -402
- package/bin/trackops.js +116 -116
- package/lib/config.js +326 -326
- package/lib/control.js +208 -208
- package/lib/env.js +244 -244
- package/lib/init.js +325 -325
- package/lib/locale.js +24 -0
- package/lib/opera-bootstrap.js +941 -874
- package/lib/opera.js +494 -477
- package/lib/preferences.js +74 -74
- package/lib/registry.js +214 -196
- package/lib/release.js +56 -56
- package/lib/runtime-state.js +144 -144
- package/lib/server.js +312 -207
- package/lib/skills.js +74 -57
- package/lib/workspace.js +260 -260
- package/locales/en.json +192 -166
- package/locales/es.json +192 -166
- package/package.json +61 -58
- package/scripts/postinstall-locale.js +21 -21
- package/scripts/skills-marketplace-smoke.js +124 -124
- package/scripts/smoke-tests.js +558 -554
- package/scripts/sync-skill-version.js +21 -21
- package/scripts/validate-skill.js +103 -103
- package/skills/trackops/SKILL.md +126 -122
- package/skills/trackops/agents/openai.yaml +7 -7
- package/skills/trackops/locales/en/SKILL.md +126 -122
- package/skills/trackops/locales/en/references/activation.md +94 -75
- package/skills/trackops/locales/en/references/troubleshooting.md +73 -55
- package/skills/trackops/locales/en/references/workflow.md +55 -32
- package/skills/trackops/references/activation.md +94 -75
- package/skills/trackops/references/troubleshooting.md +73 -55
- package/skills/trackops/references/workflow.md +55 -32
- package/skills/trackops/skill.json +29 -29
- package/templates/hooks/post-checkout +2 -2
- package/templates/hooks/post-commit +2 -2
- package/templates/hooks/post-merge +2 -2
- package/templates/opera/agent.md +28 -27
- package/templates/opera/architecture/dependency-graph.md +24 -24
- package/templates/opera/architecture/runtime-automation.md +24 -24
- package/templates/opera/architecture/runtime-operations.md +34 -34
- package/templates/opera/en/agent.md +22 -21
- package/templates/opera/en/architecture/dependency-graph.md +24 -24
- package/templates/opera/en/architecture/runtime-automation.md +24 -24
- package/templates/opera/en/architecture/runtime-operations.md +34 -34
- package/templates/opera/en/reviews/delivery-audit.md +18 -18
- package/templates/opera/en/reviews/integration-audit.md +18 -18
- package/templates/opera/en/router.md +24 -19
- package/templates/opera/references/autonomy-and-recovery.md +117 -117
- package/templates/opera/references/opera-cycle.md +193 -193
- package/templates/opera/registry.md +28 -28
- package/templates/opera/reviews/delivery-audit.md +18 -18
- package/templates/opera/reviews/integration-audit.md +18 -18
- package/templates/opera/router.md +54 -49
- package/templates/skills/changelog-updater/SKILL.md +69 -69
- package/templates/skills/commiter/SKILL.md +99 -99
- package/templates/skills/opera-contract-auditor/SKILL.md +38 -38
- package/templates/skills/opera-contract-auditor/locales/en/SKILL.md +38 -38
- package/templates/skills/opera-policy-guard/SKILL.md +26 -26
- package/templates/skills/opera-policy-guard/locales/en/SKILL.md +26 -26
- package/templates/skills/opera-skill/SKILL.md +279 -0
- package/templates/skills/opera-skill/locales/en/SKILL.md +279 -0
- package/templates/skills/opera-skill/locales/en/references/phase-dod.md +138 -0
- package/templates/skills/opera-skill/references/phase-dod.md +138 -0
- package/templates/skills/project-starter-skill/SKILL.md +150 -131
- package/templates/skills/project-starter-skill/locales/en/SKILL.md +143 -105
- package/templates/skills/project-starter-skill/references/opera-cycle.md +195 -193
- package/ui/css/base.css +284 -266
- package/ui/css/charts.css +425 -327
- package/ui/css/components.css +1107 -570
- package/ui/css/onboarding.css +133 -0
- package/ui/css/panels.css +345 -406
- package/ui/css/terminal.css +125 -0
- package/ui/css/timeline.css +58 -0
- package/ui/css/tokens.css +284 -227
- package/ui/favicon.svg +5 -5
- package/ui/index.html +99 -96
- package/ui/js/api.js +49 -13
- package/ui/js/app.js +28 -32
- package/ui/js/charts.js +526 -0
- package/ui/js/console-logger.js +172 -172
- package/ui/js/filters.js +247 -0
- package/ui/js/icons.js +129 -104
- package/ui/js/keyboard.js +229 -0
- package/ui/js/onboarding.js +33 -42
- package/ui/js/router.js +142 -125
- package/ui/js/theme.js +100 -100
- package/ui/js/time-tracker.js +248 -248
- package/ui/js/views/board.js +84 -114
- package/ui/js/views/dashboard.js +870 -0
- package/ui/js/views/flash.js +47 -47
- package/ui/js/views/projects.js +745 -0
- package/ui/js/views/scrum.js +476 -0
- package/ui/js/views/settings.js +153 -203
- package/ui/js/views/sidebar.js +37 -31
- package/ui/js/views/tasks.js +218 -101
- package/ui/js/views/timeline.js +265 -0
- package/ui/js/views/topbar.js +94 -107
- package/ui/app.js +0 -950
- package/ui/js/views/insights.js +0 -340
- package/ui/js/views/overview.js +0 -369
- package/ui/styles.css +0 -688
|
@@ -1,34 +1,34 @@
|
|
|
1
|
-
# SOP - Runtime Operations
|
|
2
|
-
|
|
3
|
-
## Purpose
|
|
4
|
-
|
|
5
|
-
Define the minimum operating procedure to keep a TrackOps + OPERA workspace healthy.
|
|
6
|
-
|
|
7
|
-
## Inputs
|
|
8
|
-
|
|
9
|
-
- `ops/project_control.json`
|
|
10
|
-
- `ops/contract/operating-contract.json`
|
|
11
|
-
- `ops/policy/autonomy.json`
|
|
12
|
-
- `ops/bootstrap/quality-report.json`
|
|
13
|
-
|
|
14
|
-
## Core checks
|
|
15
|
-
|
|
16
|
-
1. Run `trackops status`.
|
|
17
|
-
2. Run `trackops opera status`.
|
|
18
|
-
3. Run `trackops env status`.
|
|
19
|
-
4. Confirm `contract readiness` is not `hypothesis` for active delivery work.
|
|
20
|
-
5. Confirm `legacyStatus` is `supported`.
|
|
21
|
-
|
|
22
|
-
## Recovery path
|
|
23
|
-
|
|
24
|
-
1. If bootstrap is incomplete, run `trackops opera handoff --print`.
|
|
25
|
-
2. If discovery artifacts already exist, run `trackops opera bootstrap --resume`.
|
|
26
|
-
3. If operational docs drift, run `trackops sync`.
|
|
27
|
-
4. If managed artifacts drift, run `trackops opera upgrade --stable`.
|
|
28
|
-
|
|
29
|
-
## Exit criteria
|
|
30
|
-
|
|
31
|
-
- Runtime status is readable.
|
|
32
|
-
- OPERA status is readable.
|
|
33
|
-
- Contract and policy files exist.
|
|
34
|
-
- No critical blocker remains undocumented.
|
|
1
|
+
# SOP - Runtime Operations
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Define the minimum operating procedure to keep a TrackOps + OPERA workspace healthy.
|
|
6
|
+
|
|
7
|
+
## Inputs
|
|
8
|
+
|
|
9
|
+
- `ops/project_control.json`
|
|
10
|
+
- `ops/contract/operating-contract.json`
|
|
11
|
+
- `ops/policy/autonomy.json`
|
|
12
|
+
- `ops/bootstrap/quality-report.json`
|
|
13
|
+
|
|
14
|
+
## Core checks
|
|
15
|
+
|
|
16
|
+
1. Run `trackops status`.
|
|
17
|
+
2. Run `trackops opera status`.
|
|
18
|
+
3. Run `trackops env status`.
|
|
19
|
+
4. Confirm `contract readiness` is not `hypothesis` for active delivery work.
|
|
20
|
+
5. Confirm `legacyStatus` is `supported`.
|
|
21
|
+
|
|
22
|
+
## Recovery path
|
|
23
|
+
|
|
24
|
+
1. If bootstrap is incomplete, run `trackops opera handoff --print`.
|
|
25
|
+
2. If discovery artifacts already exist, run `trackops opera bootstrap --resume`.
|
|
26
|
+
3. If operational docs drift, run `trackops sync`.
|
|
27
|
+
4. If managed artifacts drift, run `trackops opera upgrade --stable`.
|
|
28
|
+
|
|
29
|
+
## Exit criteria
|
|
30
|
+
|
|
31
|
+
- Runtime status is readable.
|
|
32
|
+
- OPERA status is readable.
|
|
33
|
+
- Contract and policy files exist.
|
|
34
|
+
- No critical blocker remains undocumented.
|
|
@@ -1,27 +1,28 @@
|
|
|
1
1
|
# Project Agent: {{PROJECT_NAME}}
|
|
2
2
|
|
|
3
|
-
## Identity
|
|
4
|
-
You are the primary agent for **{{PROJECT_NAME}}**. You operate under the O.P.E.R.A. v3.0 protocol.
|
|
5
|
-
|
|
6
|
-
## Source of Truth
|
|
7
|
-
Your machine source of truth is `ops/contract/operating-contract.json`.
|
|
8
|
-
Your compiled human view is `ops/genesis.md`.
|
|
9
|
-
For operational tracking and backlog state, use `ops/project_control.json`.
|
|
10
|
-
|
|
11
|
-
## Behavior
|
|
12
|
-
- Follow the rules defined in `ops/contract/operating-contract.json` and reflected in `ops/genesis.md`.
|
|
13
|
-
- Respect `ops/policy/autonomy.json` to determine which actions are allowed without approval.
|
|
14
|
-
- Manage tasks and states from `ops/project_control.json`.
|
|
15
|
-
- Do not edit `ops/task_plan.md`, `ops/progress.md`, or `ops/findings.md` manually; regenerate them with `trackops sync`.
|
|
3
|
+
## Identity
|
|
4
|
+
You are the primary agent for **{{PROJECT_NAME}}**. You operate under the O.P.E.R.A. v3.0 protocol.
|
|
5
|
+
|
|
6
|
+
## Source of Truth
|
|
7
|
+
Your machine source of truth is `ops/contract/operating-contract.json`.
|
|
8
|
+
Your compiled human view is `ops/genesis.md`.
|
|
9
|
+
For operational tracking and backlog state, use `ops/project_control.json`.
|
|
10
|
+
|
|
11
|
+
## Behavior
|
|
12
|
+
- Follow the rules defined in `ops/contract/operating-contract.json` and reflected in `ops/genesis.md`.
|
|
13
|
+
- Respect `ops/policy/autonomy.json` to determine which actions are allowed without approval.
|
|
14
|
+
- Manage tasks and states from `ops/project_control.json`.
|
|
15
|
+
- Do not edit `ops/task_plan.md`, `ops/progress.md`, or `ops/findings.md` manually; regenerate them with `trackops sync`.
|
|
16
16
|
|
|
17
17
|
## Available Skills
|
|
18
|
-
Check `ops/.agents/skills/_registry.md` to see installed skills.
|
|
18
|
+
Check `ops/.agents/skills/_registry.md` to see installed skills.
|
|
19
|
+
If `ops/.agents/skills/opera-skill/SKILL.md` exists, treat it as the default coordinator skill before choosing other skills.
|
|
19
20
|
You can also discover new skills with `trackops skill catalog`.
|
|
20
21
|
|
|
21
|
-
## Work Cycle
|
|
22
|
-
1. Run `trackops status` at the beginning of each work block.
|
|
23
|
-
2. Read `ops/contract/operating-contract.json` and `ops/genesis.md` to understand the contract and its human view.
|
|
24
|
-
3. Use `trackops next` to inspect the prioritized queue.
|
|
25
|
-
4. Before implementing, mark the task with `trackops task start <task-id>`.
|
|
26
|
-
5. Use the router in `ops/.agent/hub/router.md` to choose the right skill.
|
|
27
|
-
6. When you finish, move the task to `review`, `complete`, or `block`, then run `trackops sync`.
|
|
22
|
+
## Work Cycle
|
|
23
|
+
1. Run `trackops status` at the beginning of each work block.
|
|
24
|
+
2. Read `ops/contract/operating-contract.json` and `ops/genesis.md` to understand the contract and its human view.
|
|
25
|
+
3. Use `trackops next` to inspect the prioritized queue.
|
|
26
|
+
4. Before implementing, mark the task with `trackops task start <task-id>`.
|
|
27
|
+
5. Use the router in `ops/.agent/hub/router.md` to choose the right skill.
|
|
28
|
+
6. When you finish, move the task to `review`, `complete`, or `block`, then run `trackops sync`.
|
|
@@ -1,24 +1,24 @@
|
|
|
1
|
-
# Dependency Graph
|
|
2
|
-
|
|
3
|
-
```mermaid
|
|
4
|
-
flowchart TD
|
|
5
|
-
A[Explicit global runtime install] --> B[trackops init]
|
|
6
|
-
B --> C[trackops opera install]
|
|
7
|
-
C --> D{Routing}
|
|
8
|
-
D -->|direct_cli| E[Direct intake]
|
|
9
|
-
D -->|agent_handoff| F[agent-handoff.md/json]
|
|
10
|
-
F --> G[intake.json + spec-dossier.md]
|
|
11
|
-
E --> H[quality-report.json]
|
|
12
|
-
G --> H
|
|
13
|
-
H --> I[operating-contract.json]
|
|
14
|
-
I --> J[genesis.md]
|
|
15
|
-
I --> K[task_plan.md / progress.md / findings.md]
|
|
16
|
-
I --> L[dashboard + API state]
|
|
17
|
-
I --> M[env sync + policy enforcement]
|
|
18
|
-
```
|
|
19
|
-
|
|
20
|
-
## Notes
|
|
21
|
-
|
|
22
|
-
- `ops/project_control.json` is the operational source of truth for backlog and session state.
|
|
23
|
-
- `ops/contract/operating-contract.json` is the machine contract.
|
|
24
|
-
- `ops/genesis.md` is a compiled human view.
|
|
1
|
+
# Dependency Graph
|
|
2
|
+
|
|
3
|
+
```mermaid
|
|
4
|
+
flowchart TD
|
|
5
|
+
A[Explicit global runtime install] --> B[trackops init]
|
|
6
|
+
B --> C[trackops opera install]
|
|
7
|
+
C --> D{Routing}
|
|
8
|
+
D -->|direct_cli| E[Direct intake]
|
|
9
|
+
D -->|agent_handoff| F[agent-handoff.md/json]
|
|
10
|
+
F --> G[intake.json + spec-dossier.md]
|
|
11
|
+
E --> H[quality-report.json]
|
|
12
|
+
G --> H
|
|
13
|
+
H --> I[operating-contract.json]
|
|
14
|
+
I --> J[genesis.md]
|
|
15
|
+
I --> K[task_plan.md / progress.md / findings.md]
|
|
16
|
+
I --> L[dashboard + API state]
|
|
17
|
+
I --> M[env sync + policy enforcement]
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
## Notes
|
|
21
|
+
|
|
22
|
+
- `ops/project_control.json` is the operational source of truth for backlog and session state.
|
|
23
|
+
- `ops/contract/operating-contract.json` is the machine contract.
|
|
24
|
+
- `ops/genesis.md` is a compiled human view.
|
|
@@ -1,24 +1,24 @@
|
|
|
1
|
-
# SOP - Runtime Automation
|
|
2
|
-
|
|
3
|
-
## Objective
|
|
4
|
-
|
|
5
|
-
Keep validation automatic on every relevant change.
|
|
6
|
-
|
|
7
|
-
## Trigger policy
|
|
8
|
-
|
|
9
|
-
- Validate on push to `develop` and `master`.
|
|
10
|
-
- Validate on pull requests targeting `develop` or `master`.
|
|
11
|
-
- Allow manual execution with workflow dispatch.
|
|
12
|
-
|
|
13
|
-
## Validation circuit
|
|
14
|
-
|
|
15
|
-
1. Install Node 18 and 20.
|
|
16
|
-
2. Install runtime dependencies.
|
|
17
|
-
3. Run `npm run release:check`.
|
|
18
|
-
4. Fail fast on any smoke, skill or packaging regression.
|
|
19
|
-
|
|
20
|
-
## Release hygiene
|
|
21
|
-
|
|
22
|
-
- Do not publish if `release:check` fails.
|
|
23
|
-
- Do not treat local runtime state as deployable proof.
|
|
24
|
-
- Re-run smoke after structural or locale changes.
|
|
1
|
+
# SOP - Runtime Automation
|
|
2
|
+
|
|
3
|
+
## Objective
|
|
4
|
+
|
|
5
|
+
Keep validation automatic on every relevant change.
|
|
6
|
+
|
|
7
|
+
## Trigger policy
|
|
8
|
+
|
|
9
|
+
- Validate on push to `develop` and `master`.
|
|
10
|
+
- Validate on pull requests targeting `develop` or `master`.
|
|
11
|
+
- Allow manual execution with workflow dispatch.
|
|
12
|
+
|
|
13
|
+
## Validation circuit
|
|
14
|
+
|
|
15
|
+
1. Install Node 18 and 20.
|
|
16
|
+
2. Install runtime dependencies.
|
|
17
|
+
3. Run `npm run release:check`.
|
|
18
|
+
4. Fail fast on any smoke, skill or packaging regression.
|
|
19
|
+
|
|
20
|
+
## Release hygiene
|
|
21
|
+
|
|
22
|
+
- Do not publish if `release:check` fails.
|
|
23
|
+
- Do not treat local runtime state as deployable proof.
|
|
24
|
+
- Re-run smoke after structural or locale changes.
|
|
@@ -1,34 +1,34 @@
|
|
|
1
|
-
# SOP - Runtime Operations
|
|
2
|
-
|
|
3
|
-
## Purpose
|
|
4
|
-
|
|
5
|
-
Define the minimum operating procedure required to keep a TrackOps + OPERA workspace healthy.
|
|
6
|
-
|
|
7
|
-
## Inputs
|
|
8
|
-
|
|
9
|
-
- `ops/project_control.json`
|
|
10
|
-
- `ops/contract/operating-contract.json`
|
|
11
|
-
- `ops/policy/autonomy.json`
|
|
12
|
-
- `ops/bootstrap/quality-report.json`
|
|
13
|
-
|
|
14
|
-
## Core checks
|
|
15
|
-
|
|
16
|
-
1. Run `trackops status`.
|
|
17
|
-
2. Run `trackops opera status`.
|
|
18
|
-
3. Run `trackops env status`.
|
|
19
|
-
4. Confirm `contract readiness` is not `hypothesis` for active delivery work.
|
|
20
|
-
5. Confirm `legacyStatus` is `supported`.
|
|
21
|
-
|
|
22
|
-
## Recovery path
|
|
23
|
-
|
|
24
|
-
1. If bootstrap is incomplete, run `trackops opera handoff --print`.
|
|
25
|
-
2. If discovery artifacts already exist, run `trackops opera bootstrap --resume`.
|
|
26
|
-
3. If operational docs drift, run `trackops sync`.
|
|
27
|
-
4. If managed artifacts drift, run `trackops opera upgrade --stable`.
|
|
28
|
-
|
|
29
|
-
## Exit criteria
|
|
30
|
-
|
|
31
|
-
- Runtime status is readable.
|
|
32
|
-
- OPERA status is readable.
|
|
33
|
-
- Contract and policy files exist.
|
|
34
|
-
- No critical blocker remains undocumented.
|
|
1
|
+
# SOP - Runtime Operations
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Define the minimum operating procedure required to keep a TrackOps + OPERA workspace healthy.
|
|
6
|
+
|
|
7
|
+
## Inputs
|
|
8
|
+
|
|
9
|
+
- `ops/project_control.json`
|
|
10
|
+
- `ops/contract/operating-contract.json`
|
|
11
|
+
- `ops/policy/autonomy.json`
|
|
12
|
+
- `ops/bootstrap/quality-report.json`
|
|
13
|
+
|
|
14
|
+
## Core checks
|
|
15
|
+
|
|
16
|
+
1. Run `trackops status`.
|
|
17
|
+
2. Run `trackops opera status`.
|
|
18
|
+
3. Run `trackops env status`.
|
|
19
|
+
4. Confirm `contract readiness` is not `hypothesis` for active delivery work.
|
|
20
|
+
5. Confirm `legacyStatus` is `supported`.
|
|
21
|
+
|
|
22
|
+
## Recovery path
|
|
23
|
+
|
|
24
|
+
1. If bootstrap is incomplete, run `trackops opera handoff --print`.
|
|
25
|
+
2. If discovery artifacts already exist, run `trackops opera bootstrap --resume`.
|
|
26
|
+
3. If operational docs drift, run `trackops sync`.
|
|
27
|
+
4. If managed artifacts drift, run `trackops opera upgrade --stable`.
|
|
28
|
+
|
|
29
|
+
## Exit criteria
|
|
30
|
+
|
|
31
|
+
- Runtime status is readable.
|
|
32
|
+
- OPERA status is readable.
|
|
33
|
+
- Contract and policy files exist.
|
|
34
|
+
- No critical blocker remains undocumented.
|
|
@@ -1,18 +1,18 @@
|
|
|
1
|
-
# Delivery Audit
|
|
2
|
-
|
|
3
|
-
## Scope
|
|
4
|
-
|
|
5
|
-
Review the final output shape against the active templates and compiled contract.
|
|
6
|
-
|
|
7
|
-
## Checklist
|
|
8
|
-
|
|
9
|
-
- `ops/genesis.md` matches the current contract.
|
|
10
|
-
- `ops/task_plan.md`, `ops/progress.md` and `ops/findings.md` are synchronized.
|
|
11
|
-
- Public copy matches runtime behavior.
|
|
12
|
-
- API and dashboard reflect the same operational state.
|
|
13
|
-
- Visual review completed when a UI change exists.
|
|
14
|
-
|
|
15
|
-
## Result
|
|
16
|
-
|
|
17
|
-
- Status: pending review
|
|
18
|
-
- Notes: replace this section with project-specific evidence.
|
|
1
|
+
# Delivery Audit
|
|
2
|
+
|
|
3
|
+
## Scope
|
|
4
|
+
|
|
5
|
+
Review the final output shape against the active templates and compiled contract.
|
|
6
|
+
|
|
7
|
+
## Checklist
|
|
8
|
+
|
|
9
|
+
- `ops/genesis.md` matches the current contract.
|
|
10
|
+
- `ops/task_plan.md`, `ops/progress.md` and `ops/findings.md` are synchronized.
|
|
11
|
+
- Public copy matches runtime behavior.
|
|
12
|
+
- API and dashboard reflect the same operational state.
|
|
13
|
+
- Visual review completed when a UI change exists.
|
|
14
|
+
|
|
15
|
+
## Result
|
|
16
|
+
|
|
17
|
+
- Status: pending review
|
|
18
|
+
- Notes: replace this section with project-specific evidence.
|
|
@@ -1,18 +1,18 @@
|
|
|
1
|
-
# Integration Audit
|
|
2
|
-
|
|
3
|
-
## Scope
|
|
4
|
-
|
|
5
|
-
Review credentials, connectivity assumptions and external response shapes before expanding delivery.
|
|
6
|
-
|
|
7
|
-
## Checklist
|
|
8
|
-
|
|
9
|
-
- Required keys identified from the contract and environment contract.
|
|
10
|
-
- Missing keys documented without exposing secret values.
|
|
11
|
-
- External services listed in the contract.
|
|
12
|
-
- Response shapes aligned with `ops/contract/operating-contract.json`.
|
|
13
|
-
- Findings recorded in `ops/findings.md` when applicable.
|
|
14
|
-
|
|
15
|
-
## Result
|
|
16
|
-
|
|
17
|
-
- Status: pending review
|
|
18
|
-
- Notes: replace this section with project-specific evidence.
|
|
1
|
+
# Integration Audit
|
|
2
|
+
|
|
3
|
+
## Scope
|
|
4
|
+
|
|
5
|
+
Review credentials, connectivity assumptions and external response shapes before expanding delivery.
|
|
6
|
+
|
|
7
|
+
## Checklist
|
|
8
|
+
|
|
9
|
+
- Required keys identified from the contract and environment contract.
|
|
10
|
+
- Missing keys documented without exposing secret values.
|
|
11
|
+
- External services listed in the contract.
|
|
12
|
+
- Response shapes aligned with `ops/contract/operating-contract.json`.
|
|
13
|
+
- Findings recorded in `ops/findings.md` when applicable.
|
|
14
|
+
|
|
15
|
+
## Result
|
|
16
|
+
|
|
17
|
+
- Status: pending review
|
|
18
|
+
- Notes: replace this section with project-specific evidence.
|
|
@@ -5,6 +5,11 @@ This file defines the routing rules between the main agent and the available ski
|
|
|
5
5
|
|
|
6
6
|
## Routing Rules
|
|
7
7
|
|
|
8
|
+
### Context: OPERA operational coordination
|
|
9
|
+
- **Trigger**: The project has OPERA installed and the user asks what to do now, which phase the project is in, whether it can advance, which command to use, or whether to delegate.
|
|
10
|
+
- **Skill**: `opera-skill`
|
|
11
|
+
- **Action**: Consult it first to decide phase, state, blocking, commands, and delegable skills. If `opera-skill` is installed, treat it as the default coordinator before choosing other skills.
|
|
12
|
+
|
|
8
13
|
### Context: Code commit
|
|
9
14
|
- **Trigger**: The user asks for a commit or a code change has just been completed.
|
|
10
15
|
- **Skill**: `commiter`
|
|
@@ -15,25 +20,25 @@ This file defines the routing rules between the main agent and the available ski
|
|
|
15
20
|
- **Skill**: `changelog-updater`
|
|
16
21
|
- **Action**: Run the changelog update flow.
|
|
17
22
|
|
|
18
|
-
### Context: Agent-led project start
|
|
19
|
-
- **Trigger**: The user has an idea, partial specification, or TrackOps has generated `ops/bootstrap/agent-handoff.md`.
|
|
20
|
-
- **Skill**: `project-starter-skill`
|
|
21
|
-
- **Action**: Turn the user context into `ops/bootstrap/intake.json`, `ops/bootstrap/spec-dossier.md`, and `ops/bootstrap/open-questions.md` when needed.
|
|
22
|
-
|
|
23
|
-
### Context: Contract audit
|
|
24
|
-
- **Trigger**: `ops/contract/operating-contract.json` or `ops/bootstrap/quality-report.json` exists and there are doubts about gaps or contradictions.
|
|
25
|
-
- **Skill**: `opera-contract-auditor`
|
|
26
|
-
- **Action**: Audit consistency, gaps, and false precision before execution continues.
|
|
27
|
-
|
|
28
|
-
### Context: Operational risk
|
|
29
|
-
- **Trigger**: The action affects persistent data, deployments, external side effects, or sensitive permissions.
|
|
30
|
-
- **Skill**: `opera-policy-guard`
|
|
31
|
-
- **Action**: Read `ops/policy/autonomy.json` and decide whether explicit approval is required.
|
|
32
|
-
|
|
33
|
-
### Context: Operational tracking
|
|
34
|
-
- **Trigger**: A work block is about to start, resume, or close.
|
|
35
|
-
- **Skill**: No external skill.
|
|
36
|
-
- **Action**: Run `trackops status`, take the next task with `trackops next`, use `ops/contract/operating-contract.json` as the machine contract, and keep `ops/project_control.json` as the backlog source of truth.
|
|
23
|
+
### Context: Agent-led project start
|
|
24
|
+
- **Trigger**: The user has an idea, partial specification, or TrackOps has generated `ops/bootstrap/agent-handoff.md`.
|
|
25
|
+
- **Skill**: `project-starter-skill`
|
|
26
|
+
- **Action**: Turn the user context into `ops/bootstrap/intake.json`, `ops/bootstrap/spec-dossier.md`, and `ops/bootstrap/open-questions.md` when needed.
|
|
27
|
+
|
|
28
|
+
### Context: Contract audit
|
|
29
|
+
- **Trigger**: `ops/contract/operating-contract.json` or `ops/bootstrap/quality-report.json` exists and there are doubts about gaps or contradictions.
|
|
30
|
+
- **Skill**: `opera-contract-auditor`
|
|
31
|
+
- **Action**: Audit consistency, gaps, and false precision before execution continues.
|
|
32
|
+
|
|
33
|
+
### Context: Operational risk
|
|
34
|
+
- **Trigger**: The action affects persistent data, deployments, external side effects, or sensitive permissions.
|
|
35
|
+
- **Skill**: `opera-policy-guard`
|
|
36
|
+
- **Action**: Read `ops/policy/autonomy.json` and decide whether explicit approval is required.
|
|
37
|
+
|
|
38
|
+
### Context: Operational tracking
|
|
39
|
+
- **Trigger**: A work block is about to start, resume, or close.
|
|
40
|
+
- **Skill**: No external skill.
|
|
41
|
+
- **Action**: Run `trackops status`, take the next task with `trackops next`, use `ops/contract/operating-contract.json` as the machine contract, and keep `ops/project_control.json` as the backlog source of truth.
|
|
37
42
|
|
|
38
43
|
## Adding New Rules
|
|
39
44
|
|
|
@@ -1,117 +1,117 @@
|
|
|
1
|
-
# Gobernanza, Autonomía y Recuperación
|
|
2
|
-
|
|
3
|
-
Este documento define los niveles de permiso, el protocolo de auto-reparación y el sistema de rollback para el proyecto.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 🚦 Matriz de Autonomía (Semáforo)
|
|
8
|
-
|
|
9
|
-
### 🔴 NIVEL ROJO — Detente y Pide Permiso
|
|
10
|
-
|
|
11
|
-
Estas acciones requieren aprobación explícita del usuario antes de ejecutarse:
|
|
12
|
-
|
|
13
|
-
- Modificar la estructura de datos o reglas en `genesis.md`.
|
|
14
|
-
- Eliminar datos persistentes o archivos fuera de `.tmp/`.
|
|
15
|
-
- Despliegue final a producción (Fase de Automatizar).
|
|
16
|
-
- Envío de comunicaciones reales a terceros (emails, webhooks con side-effects).
|
|
17
|
-
- Creación de repositorios o recursos en servicios externos (GitHub, cloud).
|
|
18
|
-
- Modificar configuraciones de acceso o seguridad.
|
|
19
|
-
|
|
20
|
-
### 🟡 NIVEL AMARILLO — Avanza con Precaución
|
|
21
|
-
|
|
22
|
-
Estas acciones se pueden ejecutar pero requieren documentación inmediata:
|
|
23
|
-
|
|
24
|
-
- Instalación de dependencias nuevas.
|
|
25
|
-
- Modificaciones a la estructura de directorios.
|
|
26
|
-
- Cambios en el pipeline documentado en `genesis.md`.
|
|
27
|
-
|
|
28
|
-
### 🟢 NIVEL VERDE — Avanza con Confianza
|
|
29
|
-
|
|
30
|
-
Estas acciones no requieren permiso:
|
|
31
|
-
|
|
32
|
-
- Creación, edición y corrección de scripts en `tools/`.
|
|
33
|
-
- Lectura de archivos y documentación.
|
|
34
|
-
- Ejecución de pruebas (Tests).
|
|
35
|
-
- Actualización de `progress.md`, `findings.md` y `task_plan.md`.
|
|
36
|
-
- Instalación de skills del ecosistema.
|
|
37
|
-
- Escritura y limpieza de archivos en `.tmp/`.
|
|
38
|
-
- Auto-Reparación (con límite de reintentos).
|
|
39
|
-
|
|
40
|
-
---
|
|
41
|
-
|
|
42
|
-
## 🛠️ Principio de Auto-Templado (Self-Annealing)
|
|
43
|
-
|
|
44
|
-
Cuando una herramienta falla o ocurre un error en Nivel Verde, sigue este protocolo:
|
|
45
|
-
|
|
46
|
-
### Procedimiento
|
|
47
|
-
|
|
48
|
-
1. **Analizar**: Lee el stack trace completo. No adivines la causa.
|
|
49
|
-
2. **Parchear**: Arregla el script en `tools/`.
|
|
50
|
-
3. **Probar**: Verifica que el arreglo funciona ejecutando el script.
|
|
51
|
-
4. **Actualizar Memoria**: Documenta el aprendizaje en `findings.md` o en el SOP correspondiente en `architecture/` para que el error nunca se repita.
|
|
52
|
-
|
|
53
|
-
### Límite de Reintentos
|
|
54
|
-
|
|
55
|
-
**Máximo 3 intentos de auto-reparación por error.** Si al tercer intento el error persiste:
|
|
56
|
-
|
|
57
|
-
1. **Escalar a Nivel Rojo** — Pide intervención humana.
|
|
58
|
-
2. **Documentar el bloqueo** en `findings.md` con:
|
|
59
|
-
|
|
60
|
-
```markdown
|
|
61
|
-
## Bloqueo: [nombre del error]
|
|
62
|
-
### Fecha: [YYYY-MM-DD]
|
|
63
|
-
### Script: [tools/nombre.py]
|
|
64
|
-
|
|
65
|
-
### Stack Trace
|
|
66
|
-
[pegar stack trace completo]
|
|
67
|
-
|
|
68
|
-
### Intentos de Reparación
|
|
69
|
-
1. **Intento 1**: [qué se intentó] → [resultado]
|
|
70
|
-
2. **Intento 2**: [qué se intentó] → [resultado]
|
|
71
|
-
3. **Intento 3**: [qué se intentó] → [resultado]
|
|
72
|
-
|
|
73
|
-
### Hipótesis del Problema Raíz
|
|
74
|
-
[análisis de por qué crees que falla]
|
|
75
|
-
|
|
76
|
-
### Acción Requerida
|
|
77
|
-
[qué necesitas del usuario para desbloquear]
|
|
78
|
-
```
|
|
79
|
-
|
|
80
|
-
### Lo que NO es Auto-Templado
|
|
81
|
-
|
|
82
|
-
- No es reintentar ciegamente el mismo comando esperando un resultado diferente.
|
|
83
|
-
- No es ignorar el error y continuar.
|
|
84
|
-
- No es cambiar el schema en `genesis.md` para que el error "desaparezca".
|
|
85
|
-
|
|
86
|
-
---
|
|
87
|
-
|
|
88
|
-
## 🔄 Protocolo de Rollback
|
|
89
|
-
|
|
90
|
-
Si una fase posterior invalida una decisión de una fase anterior, NO modifiques `genesis.md` directamente.
|
|
91
|
-
|
|
92
|
-
### Procedimiento
|
|
93
|
-
|
|
94
|
-
1. **Documentar** en `CHANGELOG.md` qué cambio se necesita y por qué.
|
|
95
|
-
2. **Solicitar aprobación** (Nivel Rojo).
|
|
96
|
-
3. **Una vez aprobado**, actualizar `genesis.md` con nueva versión:
|
|
97
|
-
|
|
98
|
-
```markdown
|
|
99
|
-
## Versión 1.1 — [fecha]
|
|
100
|
-
|
|
101
|
-
### Cambio
|
|
102
|
-
- [descripción precisa del cambio]
|
|
103
|
-
|
|
104
|
-
### Motivo
|
|
105
|
-
- [por qué la versión anterior era incorrecta o insuficiente]
|
|
106
|
-
|
|
107
|
-
### Impacto
|
|
108
|
-
- [qué scripts/SOPs necesitan actualizarse como consecuencia]
|
|
109
|
-
```
|
|
110
|
-
|
|
111
|
-
4. **Propagar el cambio**: Actualizar todos los scripts y SOPs afectados.
|
|
112
|
-
5. **Re-ejecutar tests**: Verificar que los cambios no rompen nada.
|
|
113
|
-
6. **Actualizar `progress.md`** con el rollback documentado.
|
|
114
|
-
|
|
115
|
-
### Regla de Oro
|
|
116
|
-
|
|
117
|
-
El historial de decisiones nunca se borra. Cada versión de `genesis.md` queda registrada en `CHANGELOG.md`. Esto permite entender por qué se tomó una decisión y por qué se cambió, evitando ciclos de decisiones contradictorias.
|
|
1
|
+
# Gobernanza, Autonomía y Recuperación
|
|
2
|
+
|
|
3
|
+
Este documento define los niveles de permiso, el protocolo de auto-reparación y el sistema de rollback para el proyecto.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 🚦 Matriz de Autonomía (Semáforo)
|
|
8
|
+
|
|
9
|
+
### 🔴 NIVEL ROJO — Detente y Pide Permiso
|
|
10
|
+
|
|
11
|
+
Estas acciones requieren aprobación explícita del usuario antes de ejecutarse:
|
|
12
|
+
|
|
13
|
+
- Modificar la estructura de datos o reglas en `genesis.md`.
|
|
14
|
+
- Eliminar datos persistentes o archivos fuera de `.tmp/`.
|
|
15
|
+
- Despliegue final a producción (Fase de Automatizar).
|
|
16
|
+
- Envío de comunicaciones reales a terceros (emails, webhooks con side-effects).
|
|
17
|
+
- Creación de repositorios o recursos en servicios externos (GitHub, cloud).
|
|
18
|
+
- Modificar configuraciones de acceso o seguridad.
|
|
19
|
+
|
|
20
|
+
### 🟡 NIVEL AMARILLO — Avanza con Precaución
|
|
21
|
+
|
|
22
|
+
Estas acciones se pueden ejecutar pero requieren documentación inmediata:
|
|
23
|
+
|
|
24
|
+
- Instalación de dependencias nuevas.
|
|
25
|
+
- Modificaciones a la estructura de directorios.
|
|
26
|
+
- Cambios en el pipeline documentado en `genesis.md`.
|
|
27
|
+
|
|
28
|
+
### 🟢 NIVEL VERDE — Avanza con Confianza
|
|
29
|
+
|
|
30
|
+
Estas acciones no requieren permiso:
|
|
31
|
+
|
|
32
|
+
- Creación, edición y corrección de scripts en `tools/`.
|
|
33
|
+
- Lectura de archivos y documentación.
|
|
34
|
+
- Ejecución de pruebas (Tests).
|
|
35
|
+
- Actualización de `progress.md`, `findings.md` y `task_plan.md`.
|
|
36
|
+
- Instalación de skills del ecosistema.
|
|
37
|
+
- Escritura y limpieza de archivos en `.tmp/`.
|
|
38
|
+
- Auto-Reparación (con límite de reintentos).
|
|
39
|
+
|
|
40
|
+
---
|
|
41
|
+
|
|
42
|
+
## 🛠️ Principio de Auto-Templado (Self-Annealing)
|
|
43
|
+
|
|
44
|
+
Cuando una herramienta falla o ocurre un error en Nivel Verde, sigue este protocolo:
|
|
45
|
+
|
|
46
|
+
### Procedimiento
|
|
47
|
+
|
|
48
|
+
1. **Analizar**: Lee el stack trace completo. No adivines la causa.
|
|
49
|
+
2. **Parchear**: Arregla el script en `tools/`.
|
|
50
|
+
3. **Probar**: Verifica que el arreglo funciona ejecutando el script.
|
|
51
|
+
4. **Actualizar Memoria**: Documenta el aprendizaje en `findings.md` o en el SOP correspondiente en `architecture/` para que el error nunca se repita.
|
|
52
|
+
|
|
53
|
+
### Límite de Reintentos
|
|
54
|
+
|
|
55
|
+
**Máximo 3 intentos de auto-reparación por error.** Si al tercer intento el error persiste:
|
|
56
|
+
|
|
57
|
+
1. **Escalar a Nivel Rojo** — Pide intervención humana.
|
|
58
|
+
2. **Documentar el bloqueo** en `findings.md` con:
|
|
59
|
+
|
|
60
|
+
```markdown
|
|
61
|
+
## Bloqueo: [nombre del error]
|
|
62
|
+
### Fecha: [YYYY-MM-DD]
|
|
63
|
+
### Script: [tools/nombre.py]
|
|
64
|
+
|
|
65
|
+
### Stack Trace
|
|
66
|
+
[pegar stack trace completo]
|
|
67
|
+
|
|
68
|
+
### Intentos de Reparación
|
|
69
|
+
1. **Intento 1**: [qué se intentó] → [resultado]
|
|
70
|
+
2. **Intento 2**: [qué se intentó] → [resultado]
|
|
71
|
+
3. **Intento 3**: [qué se intentó] → [resultado]
|
|
72
|
+
|
|
73
|
+
### Hipótesis del Problema Raíz
|
|
74
|
+
[análisis de por qué crees que falla]
|
|
75
|
+
|
|
76
|
+
### Acción Requerida
|
|
77
|
+
[qué necesitas del usuario para desbloquear]
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
### Lo que NO es Auto-Templado
|
|
81
|
+
|
|
82
|
+
- No es reintentar ciegamente el mismo comando esperando un resultado diferente.
|
|
83
|
+
- No es ignorar el error y continuar.
|
|
84
|
+
- No es cambiar el schema en `genesis.md` para que el error "desaparezca".
|
|
85
|
+
|
|
86
|
+
---
|
|
87
|
+
|
|
88
|
+
## 🔄 Protocolo de Rollback
|
|
89
|
+
|
|
90
|
+
Si una fase posterior invalida una decisión de una fase anterior, NO modifiques `genesis.md` directamente.
|
|
91
|
+
|
|
92
|
+
### Procedimiento
|
|
93
|
+
|
|
94
|
+
1. **Documentar** en `CHANGELOG.md` qué cambio se necesita y por qué.
|
|
95
|
+
2. **Solicitar aprobación** (Nivel Rojo).
|
|
96
|
+
3. **Una vez aprobado**, actualizar `genesis.md` con nueva versión:
|
|
97
|
+
|
|
98
|
+
```markdown
|
|
99
|
+
## Versión 1.1 — [fecha]
|
|
100
|
+
|
|
101
|
+
### Cambio
|
|
102
|
+
- [descripción precisa del cambio]
|
|
103
|
+
|
|
104
|
+
### Motivo
|
|
105
|
+
- [por qué la versión anterior era incorrecta o insuficiente]
|
|
106
|
+
|
|
107
|
+
### Impacto
|
|
108
|
+
- [qué scripts/SOPs necesitan actualizarse como consecuencia]
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
4. **Propagar el cambio**: Actualizar todos los scripts y SOPs afectados.
|
|
112
|
+
5. **Re-ejecutar tests**: Verificar que los cambios no rompen nada.
|
|
113
|
+
6. **Actualizar `progress.md`** con el rollback documentado.
|
|
114
|
+
|
|
115
|
+
### Regla de Oro
|
|
116
|
+
|
|
117
|
+
El historial de decisiones nunca se borra. Cada versión de `genesis.md` queda registrada en `CHANGELOG.md`. Esto permite entender por qué se tomó una decisión y por qué se cambió, evitando ciclos de decisiones contradictorias.
|