superbee 0.4.4-pre.11 → 0.4.4-pre.12
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/SKILL.md +1 -1
- package/dist/superbee.mjs +1471 -1238
- package/package.json +1 -1
- package/references/hosted-checkout.md +27 -0
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "superbee",
|
|
3
|
-
"version": "0.4.4-pre.
|
|
3
|
+
"version": "0.4.4-pre.12",
|
|
4
4
|
"type": "module",
|
|
5
5
|
"description": "Agent-facing Superbee CLI for reading and writing local OKF knowledge bundles: context notes, docs, cross-links, and live bundle Views.",
|
|
6
6
|
"keywords": [
|
|
@@ -92,6 +92,33 @@ must already be a member of the workspace (invited from the Members page first).
|
|
|
92
92
|
bundle id in their own terminal. If it refuses with `needs_person_at_terminal`, show the person
|
|
93
93
|
the host's statement and give them the command; do not try to work around it.
|
|
94
94
|
|
|
95
|
+
## Requesting GitHub workload access
|
|
96
|
+
|
|
97
|
+
A GitHub Actions job can use `superbee workload exec` with a bounded version1 JSON intent, an
|
|
98
|
+
explicit HTTPS workspace origin and workspace slug, followed by its command after `--`.
|
|
99
|
+
Run its `--help` for exact syntax. The intent contains a display name, supported events, exact
|
|
100
|
+
bundle read/write capabilities and optional fixed sites. It contains no repository IDs, workflow
|
|
101
|
+
refs, environment, credentials or app UUID. Each requested site must have its matching Read bundle
|
|
102
|
+
capability. A protected main-only GitHub environment and `id-token: write` are required by the host.
|
|
103
|
+
This works for custom research or documentation workflows without `release.config.json`.
|
|
104
|
+
|
|
105
|
+
The existing exchange verifies the job's GitHub identity and resolves exactly approved access.
|
|
106
|
+
Pending approval is `FORBIDDEN` (exit 2) with `details.reason: workload_approval_pending`, an opaque
|
|
107
|
+
request id, expiry and `review_url`. No child starts and no Superbee bearer is returned. A workspace
|
|
108
|
+
administrator reviews the permissions at that URL and approves or denies them; an agent must not
|
|
109
|
+
approve its own request. Run the workflow again after approval. There is no polling, implicit grant,
|
|
110
|
+
UUID fallback or copied app-ID variable. Denied or expired requests remain terminal.
|
|
111
|
+
|
|
112
|
+
On success only the child receives the short-lived bearer, resolved gateway host, and
|
|
113
|
+
`SUPERBEE_WORKLOAD_APP_ID` from the validated response, replacing any inherited app ID. The latter
|
|
114
|
+
is temporary identity metadata for a native principal check, never a grant; nothing is written to
|
|
115
|
+
`GITHUB_ENV`, a file or a persistent GitHub variable. Its GitHub OIDC minting variables are removed. The command is spawned directly with its argument boundaries,
|
|
116
|
+
not through a shell, and its exit status is preserved. Tokens are masked in GitHub Actions logs;
|
|
117
|
+
do not print or upload the child's environment. A changed capability declaration needs its own
|
|
118
|
+
approval and cannot silently inherit broader access. The host must serve this request mode before
|
|
119
|
+
using it; merged client source alone does not establish deployment, registration or production
|
|
120
|
+
qualification. Existing explicit app-ID clients and the registration fallback below remain supported.
|
|
121
|
+
|
|
95
122
|
## Registering a site's CI: `workload register`
|
|
96
123
|
|
|
97
124
|
A site whose content lives in hosted Superbee reads it in CI as a registered workload app. In the
|