taskchef 7.15.2 → 7.15.3
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/.codex-plugin/plugin.json +1 -1
- package/README.md +25 -3
- package/package.json +1 -1
- package/skills/taskchef-bootstrap/SKILL.md +61 -16
package/README.md
CHANGED
|
@@ -59,6 +59,23 @@ $taskchef-bootstrap List my configured TaskChef projects.
|
|
|
59
59
|
$taskchef-bootstrap Add /workspace/payments as payments. It owns authorization, capture, refunds, and retries.
|
|
60
60
|
```
|
|
61
61
|
|
|
62
|
+
The bootstrap skill has two onboarding paths. For a folder already saved as a
|
|
63
|
+
local Codex project, it requires an exact canonical-path match before adding and
|
|
64
|
+
verifying the TaskChef project. For a new folder, or an existing folder not yet
|
|
65
|
+
saved by Codex, it creates the directory only when explicitly requested, opens
|
|
66
|
+
the canonical path with the validated Codex Desktop CLI's `codex app <path>`
|
|
67
|
+
mechanism, re-lists native projects, and requires the same exact match before
|
|
68
|
+
adding it to TaskChef. An open request without a verified native project is
|
|
69
|
+
reported as partial setup, not delegation-ready.
|
|
70
|
+
|
|
71
|
+
Codex CLI resolution follows the same contract as
|
|
72
|
+
`workspace init --register-codex`: an explicit `--codex-cli` path wins, then
|
|
73
|
+
`TASKCHEF_CODEX_CLI`; either must be executable and support `app --help`.
|
|
74
|
+
Without an override, TaskChef prefers a validated `codex` PATH candidate under
|
|
75
|
+
`Contents/Resources`; otherwise it validates only the first executable `codex`
|
|
76
|
+
in PATH order. It does not assume an arbitrary shell command or hard-code an
|
|
77
|
+
application bundle location.
|
|
78
|
+
|
|
62
79
|
Or use the CLI:
|
|
63
80
|
|
|
64
81
|
```sh
|
|
@@ -68,9 +85,14 @@ taskchef project list
|
|
|
68
85
|
```
|
|
69
86
|
|
|
70
87
|
A project may advertise several GitHub repositories with repeated
|
|
71
|
-
`--github-repo`.
|
|
72
|
-
|
|
73
|
-
|
|
88
|
+
`--github-repo`. Explicit values replace automatic origin detection and form
|
|
89
|
+
the complete advertised list, so include the origin when it should remain
|
|
90
|
+
routable. A managed `*-workspace` should advertise every relevant child or
|
|
91
|
+
subrepository canonical GitHub URL, plus the workspace repository itself when
|
|
92
|
+
applicable, so issue and pull-request links select the correct routing project.
|
|
93
|
+
TaskChef accepts Git roots and ordinary local folders on the same execution
|
|
94
|
+
host. Unsupported configuration schemas are rejected and are never rewritten
|
|
95
|
+
automatically.
|
|
74
96
|
|
|
75
97
|
## Dispatch
|
|
76
98
|
|
package/package.json
CHANGED
|
@@ -50,28 +50,73 @@ all deterministic workspace operations.
|
|
|
50
50
|
End without dispatching unless the user
|
|
51
51
|
separately requested work.
|
|
52
52
|
|
|
53
|
-
##
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
53
|
+
## Onboard a routing project
|
|
54
|
+
|
|
55
|
+
Configure only projects local to the TaskChef workspace's execution host.
|
|
56
|
+
Remote connection projects are outside the v1 contract. Never configure the
|
|
57
|
+
TaskChef dispatcher workspace or a directory containing it as a routing target;
|
|
58
|
+
the dispatcher is the inbox, while routing projects own delegated work.
|
|
59
|
+
|
|
60
|
+
### Existing Codex project
|
|
61
|
+
|
|
62
|
+
1. List native local Codex projects once. Resolve the requested existing folder
|
|
63
|
+
with `realpath` and require an exact canonical-path match in that list. A
|
|
64
|
+
similar name, a parent or child directory, and a remote connection project
|
|
65
|
+
are not matches.
|
|
66
|
+
2. Add the exact path with `project add <canonical-path> --name <curated-name>
|
|
67
|
+
--description <curated-description> --json`. The CLI detects Git status, the
|
|
68
|
+
exact Git root, and a canonical GitHub `origin` when no repository option is
|
|
69
|
+
supplied. Repeated `--github-repo <canonical-url>` arguments replace that
|
|
70
|
+
detection and form the complete advertised repository list, so repeat the
|
|
71
|
+
origin explicitly when it should remain routable. Use `--no-github` when the
|
|
72
|
+
user intentionally wants an empty list.
|
|
73
|
+
3. Run `project list --json` and require one saved TaskChef project with the
|
|
74
|
+
exact canonical path and intended routing metadata. Only then report that it
|
|
75
|
+
is ready for delegation.
|
|
76
|
+
|
|
77
|
+
### New or not-yet-saved Codex folder
|
|
78
|
+
|
|
79
|
+
1. Create the folder only when the user explicitly asked to create it. Preserve
|
|
80
|
+
unrelated existing contents. Do not initialize Git unless requested or
|
|
81
|
+
clearly required by the user's broader task. Resolve the resulting existing
|
|
82
|
+
folder with `realpath`.
|
|
83
|
+
2. Register or open that exact canonical folder with the supported
|
|
84
|
+
`<validated-codex-cli> app <canonical-path>` mechanism. Reuse a validated CLI
|
|
85
|
+
path supplied by the current Codex Desktop environment when available. Use
|
|
86
|
+
the same resolver contract as `workspace init --register-codex` otherwise:
|
|
87
|
+
an explicit `--codex-cli` path takes precedence over `TASKCHEF_CODEX_CLI`;
|
|
88
|
+
each must resolve to an executable that passes `app --help`. Without an
|
|
89
|
+
override, inspect `codex` executables from `PATH`, prefer a validated
|
|
90
|
+
candidate whose path contains `Contents/Resources`, and otherwise validate
|
|
91
|
+
only the first executable `codex` in PATH order. Never assume an arbitrary
|
|
92
|
+
shell `codex`, invoke `codex add`, or hard-code an application bundle path.
|
|
93
|
+
3. Re-list native local Codex projects and require an exact canonical-path
|
|
94
|
+
match. Opening is a request, not proof that Codex saved the project. If the
|
|
95
|
+
exact match is absent, report that the folder was opened or registration was
|
|
96
|
+
requested but Codex registration remains unverified; do not add it to
|
|
97
|
+
TaskChef or call it delegation-ready.
|
|
98
|
+
4. After Codex verification, add the project as in the existing-project path.
|
|
99
|
+
Run `project list --json` and verify the exact saved TaskChef project. Report
|
|
100
|
+
delegation readiness only after both the native Codex match and TaskChef
|
|
101
|
+
registration are verified.
|
|
102
|
+
|
|
103
|
+
For a managed `*-workspace` routing project, advertise every relevant child or
|
|
104
|
+
subrepository with repeated `--github-repo <canonical-github-url>` arguments,
|
|
105
|
+
including the workspace repository itself when it can own issue or pull-request
|
|
106
|
+
links. These explicit values are the complete list; automatic origin detection
|
|
107
|
+
does not supplement them. This lets TaskChef route each canonical GitHub URL to
|
|
108
|
+
the correct workspace rather than guessing from the folder name.
|
|
109
|
+
|
|
110
|
+
## Manage configured projects
|
|
111
|
+
|
|
112
|
+
1. Bulk import with `project import <file|-> --json`. Input is a JSON array of
|
|
68
113
|
objects containing `path` plus optional `name`, `description`, and
|
|
69
114
|
`githubRepos`, which is always a JSON array of GitHub repository URLs. Import
|
|
70
115
|
merges by canonical path, preserves an existing name or description when
|
|
71
116
|
omitted, and unions existing and imported repository lists without
|
|
72
117
|
duplicates. Use `--replace` only when the user explicitly requests
|
|
73
118
|
replacement.
|
|
74
|
-
|
|
119
|
+
2. Inspect configured projects with `project list --json`. Remove by name with
|
|
75
120
|
`project remove`. Existing task entries keep their project snapshots.
|
|
76
121
|
|
|
77
122
|
Example managed-workspace import entry:
|