@dynamicagents/plugins 0.11.0 → 0.12.0
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/README.md +12 -13
- package/dist/arc-agi/analysis.d.ts +16 -30
- package/dist/arc-agi/analysis.js +20 -47
- package/dist/arc-agi/client.d.ts +3 -2
- package/dist/arc-agi/game-tools.d.ts +5 -6
- package/dist/arc-agi/index.d.ts +6 -8
- package/dist/arc-agi/index.js +3 -3
- package/dist/arc-agi/main-agent.d.ts +5 -8
- package/dist/arc-agi/main-agent.js +5 -8
- package/dist/arc-agi/recipe.d.ts +17 -20
- package/dist/arc-agi/recipe.js +17 -20
- package/dist/arc-agi/soul.d.ts +16 -27
- package/dist/arc-agi/soul.js +16 -27
- package/dist/arc-agi/store.d.ts +4 -5
- package/dist/arc-agi/store.js +4 -5
- package/dist/arc-agi/tools.d.ts +1 -1
- package/dist/arc-agi/tools.js +26 -19
- package/dist/arc-agi/types.d.ts +6 -7
- package/dist/claude-code/config.d.ts +88 -11
- package/dist/claude-code/config.js +11 -2
- package/dist/claude-code/credentials.d.ts +21 -9
- package/dist/claude-code/credentials.js +43 -9
- package/dist/claude-code/egress.d.ts +7 -13
- package/dist/claude-code/egress.js +9 -10
- package/dist/claude-code/events.d.ts +47 -0
- package/dist/claude-code/events.js +96 -10
- package/dist/claude-code/index.d.ts +31 -13
- package/dist/claude-code/index.js +62 -15
- package/dist/claude-code/run.d.ts +135 -41
- package/dist/claude-code/run.js +366 -61
- package/dist/computer/advisory.d.ts +31 -18
- package/dist/computer/advisory.js +30 -5
- package/dist/computer/context.d.ts +23 -0
- package/dist/computer/context.js +225 -0
- package/dist/computer/file-lock.d.ts +5 -0
- package/dist/computer/file-lock.js +39 -0
- package/dist/computer/gate.d.ts +8 -8
- package/dist/computer/gate.js +7 -7
- package/dist/computer/host/ca-trust.d.ts +88 -0
- package/dist/computer/host/ca-trust.js +303 -0
- package/dist/computer/host/container-deps.d.ts +54 -0
- package/dist/computer/host/container-deps.js +224 -0
- package/dist/computer/host/container-fault.d.ts +38 -0
- package/dist/computer/host/container-fault.js +58 -0
- package/dist/computer/host/git-host.d.ts +62 -0
- package/dist/computer/host/git-host.js +156 -0
- package/dist/computer/host/git-identity.d.ts +57 -0
- package/dist/computer/host/git-identity.js +147 -0
- package/dist/computer/host/install-job.d.ts +121 -0
- package/dist/computer/host/install-job.js +766 -0
- package/dist/computer/host/sync.d.ts +111 -0
- package/dist/computer/host/sync.js +124 -0
- package/dist/computer/host/wake.d.ts +19 -0
- package/dist/computer/host/wake.js +10 -0
- package/dist/computer/host/workspace.d.ts +424 -0
- package/dist/computer/host/workspace.js +1258 -0
- package/dist/computer/index.d.ts +70 -50
- package/dist/computer/index.js +79 -767
- package/dist/computer/install.d.ts +8 -12
- package/dist/computer/install.js +6 -9
- package/dist/computer/paths.d.ts +21 -16
- package/dist/computer/paths.js +40 -38
- package/dist/computer/read.d.ts +18 -22
- package/dist/computer/read.js +24 -27
- package/dist/computer/render.d.ts +28 -0
- package/dist/computer/render.js +34 -1
- package/dist/computer/shell.d.ts +45 -0
- package/dist/computer/shell.js +80 -0
- package/dist/computer/tools-exec.d.ts +3 -0
- package/dist/computer/tools-exec.js +269 -0
- package/dist/computer/tools-file.d.ts +4 -0
- package/dist/computer/tools-file.js +124 -0
- package/dist/computer/tools-find.d.ts +3 -0
- package/dist/computer/tools-find.js +216 -0
- package/dist/recall/index.d.ts +9 -3
- package/dist/recall/index.js +22 -12
- package/dist/repo/checkout.d.ts +34 -4
- package/dist/repo/checkout.js +36 -1
- package/dist/repo/context.d.ts +109 -0
- package/dist/repo/context.js +530 -0
- package/dist/repo/index.d.ts +6 -29
- package/dist/repo/index.js +17 -1027
- package/dist/repo/tools-clone.d.ts +4 -0
- package/dist/repo/tools-clone.js +192 -0
- package/dist/repo/tools-forge.d.ts +4 -0
- package/dist/repo/tools-forge.js +179 -0
- package/dist/repo/tools-review.d.ts +3 -0
- package/dist/repo/tools-review.js +373 -0
- package/dist/repo/tools-worktree.d.ts +4 -0
- package/dist/repo/tools-worktree.js +221 -0
- package/dist/triage/index.d.ts +6 -1
- package/dist/triage/index.js +32 -23
- package/dist/workspace/index.d.ts +3 -3
- package/dist/workspace/index.js +3 -3
- package/package.json +21 -15
|
@@ -0,0 +1,111 @@
|
|
|
1
|
+
import type { Workspace } from "@cloudflare/computer";
|
|
2
|
+
import type { Deadline } from "@dynamicagents/core/alarm";
|
|
3
|
+
/**
|
|
4
|
+
* The host's half of syncing: moving what the container wrote into the object.
|
|
5
|
+
*
|
|
6
|
+
* ## Why the host has a half at all
|
|
7
|
+
*
|
|
8
|
+
* Every command is bracketed by a sync — a push before it runs, a pull after it
|
|
9
|
+
* exits — and the pull is what carries its writes back into this object's
|
|
10
|
+
* SQLite. That pull can fail while the command itself succeeds: a transport that
|
|
11
|
+
* dropped, a container replaced underneath it. The library reports that on the
|
|
12
|
+
* command's result and schedules nothing of its own afterwards. What it does
|
|
13
|
+
* keep is the cursor, so a later `pull()` resumes the same operation rather than
|
|
14
|
+
* starting one.
|
|
15
|
+
*
|
|
16
|
+
* That later `pull()` is this. Without it the workspace silently lags the
|
|
17
|
+
* container: the file tools read a tree missing the last command's work, and git
|
|
18
|
+
* — which runs on this side — would commit and push it that way.
|
|
19
|
+
*/
|
|
20
|
+
/**
|
|
21
|
+
* How long one drain spends moving blocks before it comes back.
|
|
22
|
+
*
|
|
23
|
+
* The alarm is shared. Every other reason a workspace wakes is queued behind
|
|
24
|
+
* whatever the alarm is doing, so a drain that ran to completion in one
|
|
25
|
+
* invocation would hold the object for as long as the pull takes. A minute
|
|
26
|
+
* finishes an ordinary pull outright and keeps a large one from starving the
|
|
27
|
+
* install watchdog.
|
|
28
|
+
*/
|
|
29
|
+
export declare const SYNC_DRAIN_BUDGET_MS = 60000;
|
|
30
|
+
/** How soon a drain that is making progress comes back for the next block. */
|
|
31
|
+
export declare const SYNC_DRAIN_RESUME_MS = 1000;
|
|
32
|
+
/**
|
|
33
|
+
* The ceiling on the wait after a pull that failed.
|
|
34
|
+
*
|
|
35
|
+
* A failure is not a slow success: whatever broke — a container that stopped
|
|
36
|
+
* answering, a transport that will not open — is usually still broken a second
|
|
37
|
+
* later, and coming back at the resume interval would be an alarm and an error
|
|
38
|
+
* line every second for as long as the workspace stays up. Backing off turns
|
|
39
|
+
* that into a handful of attempts an hour, which is the rate a recoverable
|
|
40
|
+
* fault actually clears at.
|
|
41
|
+
*
|
|
42
|
+
* Bounded rather than abandoned, because the cursor is durable and the cost of
|
|
43
|
+
* one more attempt is one round trip: a container that comes back should be
|
|
44
|
+
* drained without anyone asking.
|
|
45
|
+
*/
|
|
46
|
+
export declare const SYNC_DRAIN_MAX_BACKOFF_MS: number;
|
|
47
|
+
/** How long to wait before a retry, after this many consecutive failures. */
|
|
48
|
+
export declare function syncRetryDelayMs(attempt: number): number;
|
|
49
|
+
/**
|
|
50
|
+
* What one drain achieved.
|
|
51
|
+
*
|
|
52
|
+
* `incomplete` and `failed` are separated because they want opposite responses.
|
|
53
|
+
* `incomplete` is a healthy drain that ran out of budget with the cursor moved,
|
|
54
|
+
* and the right answer is to come straight back. `failed` is a pull that threw
|
|
55
|
+
* with nothing to show for it, and coming straight back would spin against
|
|
56
|
+
* whatever is broken — see {@link syncRetryDelayMs}.
|
|
57
|
+
*
|
|
58
|
+
* `unavailable` is not a failure either: it is the answer when there is no
|
|
59
|
+
* container to pull from, which also means there is nothing outstanding that
|
|
60
|
+
* could still be recovered. Kept distinct from `complete` so a caller deciding
|
|
61
|
+
* whether to act on the workspace — a git push, say — can tell "nothing to move"
|
|
62
|
+
* from "nothing reachable".
|
|
63
|
+
*/
|
|
64
|
+
export type DrainOutcome = "complete" | "incomplete" | "failed" | "unavailable";
|
|
65
|
+
/**
|
|
66
|
+
* What a schedule waiting on a pull carries: how many times it has failed in a
|
|
67
|
+
* row. Both the drain's own deadline and the container-idle deferral that waits
|
|
68
|
+
* for one hold it, since both have to back off against the same fault.
|
|
69
|
+
*/
|
|
70
|
+
export interface SyncDrainIntent {
|
|
71
|
+
attempt: number;
|
|
72
|
+
}
|
|
73
|
+
export interface WorkspaceSyncDeps {
|
|
74
|
+
workspace: () => Workspace;
|
|
75
|
+
/** Whether a container is up. A drain must never start one — see {@link drain}. */
|
|
76
|
+
containerRunning: () => boolean;
|
|
77
|
+
/** Where the next block is scheduled. */
|
|
78
|
+
deadline: () => Deadline<SyncDrainIntent | undefined>;
|
|
79
|
+
tag: () => string;
|
|
80
|
+
id: () => string;
|
|
81
|
+
}
|
|
82
|
+
export declare class WorkspaceSync {
|
|
83
|
+
private readonly deps;
|
|
84
|
+
constructor(deps: WorkspaceSyncDeps);
|
|
85
|
+
/**
|
|
86
|
+
* Come back shortly and move what is still outstanding.
|
|
87
|
+
*
|
|
88
|
+
* A deadline rather than an immediate drain, because the caller is usually
|
|
89
|
+
* holding something that should not wait on a pull — an install's drain, or a
|
|
90
|
+
* request. `set` replaces whatever stood before, so arming twice is one
|
|
91
|
+
* schedule rather than two.
|
|
92
|
+
*/
|
|
93
|
+
arm(attempt?: number): Promise<void>;
|
|
94
|
+
/**
|
|
95
|
+
* Move what the container has written into this object's storage.
|
|
96
|
+
*
|
|
97
|
+
* One block per `next()`, under a budget rather than to completion, because
|
|
98
|
+
* the iterator is disposable by design: the durable state is the cursor the
|
|
99
|
+
* block just committed, so stopping is a normal thing to do and a recreated
|
|
100
|
+
* iterable picks up where this one stopped.
|
|
101
|
+
*
|
|
102
|
+
* **Never starts a container.** Opening a backend handle would launch one, and
|
|
103
|
+
* a pull against a replacement finds an empty filesystem rather than the
|
|
104
|
+
* writes it was after — the library fences that to the runtime that ran the
|
|
105
|
+
* command, but launching a container to discover so is pure cost. A stopped
|
|
106
|
+
* container also means there is nothing left to pull: whatever it held that
|
|
107
|
+
* never arrived is gone, which is why a drain runs *before* an idle deadline
|
|
108
|
+
* stops one.
|
|
109
|
+
*/
|
|
110
|
+
drain(budgetMs: number): Promise<DrainOutcome>;
|
|
111
|
+
}
|
|
@@ -0,0 +1,124 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* The host's half of syncing: moving what the container wrote into the object.
|
|
3
|
+
*
|
|
4
|
+
* ## Why the host has a half at all
|
|
5
|
+
*
|
|
6
|
+
* Every command is bracketed by a sync — a push before it runs, a pull after it
|
|
7
|
+
* exits — and the pull is what carries its writes back into this object's
|
|
8
|
+
* SQLite. That pull can fail while the command itself succeeds: a transport that
|
|
9
|
+
* dropped, a container replaced underneath it. The library reports that on the
|
|
10
|
+
* command's result and schedules nothing of its own afterwards. What it does
|
|
11
|
+
* keep is the cursor, so a later `pull()` resumes the same operation rather than
|
|
12
|
+
* starting one.
|
|
13
|
+
*
|
|
14
|
+
* That later `pull()` is this. Without it the workspace silently lags the
|
|
15
|
+
* container: the file tools read a tree missing the last command's work, and git
|
|
16
|
+
* — which runs on this side — would commit and push it that way.
|
|
17
|
+
*/
|
|
18
|
+
/**
|
|
19
|
+
* How long one drain spends moving blocks before it comes back.
|
|
20
|
+
*
|
|
21
|
+
* The alarm is shared. Every other reason a workspace wakes is queued behind
|
|
22
|
+
* whatever the alarm is doing, so a drain that ran to completion in one
|
|
23
|
+
* invocation would hold the object for as long as the pull takes. A minute
|
|
24
|
+
* finishes an ordinary pull outright and keeps a large one from starving the
|
|
25
|
+
* install watchdog.
|
|
26
|
+
*/
|
|
27
|
+
export const SYNC_DRAIN_BUDGET_MS = 60_000;
|
|
28
|
+
/** How soon a drain that is making progress comes back for the next block. */
|
|
29
|
+
export const SYNC_DRAIN_RESUME_MS = 1_000;
|
|
30
|
+
/**
|
|
31
|
+
* The ceiling on the wait after a pull that failed.
|
|
32
|
+
*
|
|
33
|
+
* A failure is not a slow success: whatever broke — a container that stopped
|
|
34
|
+
* answering, a transport that will not open — is usually still broken a second
|
|
35
|
+
* later, and coming back at the resume interval would be an alarm and an error
|
|
36
|
+
* line every second for as long as the workspace stays up. Backing off turns
|
|
37
|
+
* that into a handful of attempts an hour, which is the rate a recoverable
|
|
38
|
+
* fault actually clears at.
|
|
39
|
+
*
|
|
40
|
+
* Bounded rather than abandoned, because the cursor is durable and the cost of
|
|
41
|
+
* one more attempt is one round trip: a container that comes back should be
|
|
42
|
+
* drained without anyone asking.
|
|
43
|
+
*/
|
|
44
|
+
export const SYNC_DRAIN_MAX_BACKOFF_MS = 5 * 60_000;
|
|
45
|
+
/** How long to wait before a retry, after this many consecutive failures. */
|
|
46
|
+
export function syncRetryDelayMs(attempt) {
|
|
47
|
+
return Math.min(SYNC_DRAIN_RESUME_MS * 2 ** Math.max(0, attempt), SYNC_DRAIN_MAX_BACKOFF_MS);
|
|
48
|
+
}
|
|
49
|
+
export class WorkspaceSync {
|
|
50
|
+
deps;
|
|
51
|
+
constructor(deps) {
|
|
52
|
+
this.deps = deps;
|
|
53
|
+
}
|
|
54
|
+
/**
|
|
55
|
+
* Come back shortly and move what is still outstanding.
|
|
56
|
+
*
|
|
57
|
+
* A deadline rather than an immediate drain, because the caller is usually
|
|
58
|
+
* holding something that should not wait on a pull — an install's drain, or a
|
|
59
|
+
* request. `set` replaces whatever stood before, so arming twice is one
|
|
60
|
+
* schedule rather than two.
|
|
61
|
+
*/
|
|
62
|
+
async arm(attempt = 0) {
|
|
63
|
+
await this.deps
|
|
64
|
+
.deadline()
|
|
65
|
+
.set(new Date(Date.now() + syncRetryDelayMs(attempt)), { attempt });
|
|
66
|
+
}
|
|
67
|
+
/**
|
|
68
|
+
* Move what the container has written into this object's storage.
|
|
69
|
+
*
|
|
70
|
+
* One block per `next()`, under a budget rather than to completion, because
|
|
71
|
+
* the iterator is disposable by design: the durable state is the cursor the
|
|
72
|
+
* block just committed, so stopping is a normal thing to do and a recreated
|
|
73
|
+
* iterable picks up where this one stopped.
|
|
74
|
+
*
|
|
75
|
+
* **Never starts a container.** Opening a backend handle would launch one, and
|
|
76
|
+
* a pull against a replacement finds an empty filesystem rather than the
|
|
77
|
+
* writes it was after — the library fences that to the runtime that ran the
|
|
78
|
+
* command, but launching a container to discover so is pure cost. A stopped
|
|
79
|
+
* container also means there is nothing left to pull: whatever it held that
|
|
80
|
+
* never arrived is gone, which is why a drain runs *before* an idle deadline
|
|
81
|
+
* stops one.
|
|
82
|
+
*/
|
|
83
|
+
async drain(budgetMs) {
|
|
84
|
+
if (!this.deps.containerRunning())
|
|
85
|
+
return "unavailable";
|
|
86
|
+
const stopAt = Date.now() + budgetMs;
|
|
87
|
+
let blocks = 0;
|
|
88
|
+
let entries = 0;
|
|
89
|
+
try {
|
|
90
|
+
for await (const progress of this.deps.workspace().pull()) {
|
|
91
|
+
blocks += 1;
|
|
92
|
+
entries += progress.entries;
|
|
93
|
+
if (progress.complete) {
|
|
94
|
+
// Silent for the ordinary case — one empty block, which is what a
|
|
95
|
+
// workspace with nothing outstanding returns on every check.
|
|
96
|
+
if (blocks > 1 || entries > 0) {
|
|
97
|
+
console.info(`[${this.deps.tag()}] pull drained`, {
|
|
98
|
+
id: this.deps.id(),
|
|
99
|
+
blocks,
|
|
100
|
+
entries
|
|
101
|
+
});
|
|
102
|
+
}
|
|
103
|
+
return "complete";
|
|
104
|
+
}
|
|
105
|
+
if (Date.now() >= stopAt)
|
|
106
|
+
return "incomplete";
|
|
107
|
+
}
|
|
108
|
+
// The iterable ended without a block claiming completion, which is what a
|
|
109
|
+
// backend with nothing to sync returns. Nothing is outstanding either way.
|
|
110
|
+
return "complete";
|
|
111
|
+
}
|
|
112
|
+
catch (err) {
|
|
113
|
+
// Left outstanding rather than retried here: the cursor is durable, so the
|
|
114
|
+
// next drain resumes whatever this one committed before it threw.
|
|
115
|
+
console.error(`[${this.deps.tag()}] a pull could not be drained`, {
|
|
116
|
+
id: this.deps.id(),
|
|
117
|
+
blocks,
|
|
118
|
+
entries,
|
|
119
|
+
err: String(err)
|
|
120
|
+
});
|
|
121
|
+
return "failed";
|
|
122
|
+
}
|
|
123
|
+
}
|
|
124
|
+
}
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* What a workspace object wakes for, as one map.
|
|
3
|
+
*
|
|
4
|
+
* Its own module because the object that registers these callbacks and the
|
|
5
|
+
* `JobLifecycle` in `./install-job.ts` that schedules some of them by name both type
|
|
6
|
+
* against it, and neither should own it. A name that exists in one and not the
|
|
7
|
+
* other is then a compile error rather than a schedule that is rejected at
|
|
8
|
+
* runtime.
|
|
9
|
+
*/
|
|
10
|
+
import type { SyncDrainIntent } from "./sync.js";
|
|
11
|
+
export type WorkspaceWakeHandlers = {
|
|
12
|
+
installRun: () => Promise<void>;
|
|
13
|
+
installWatch: () => Promise<void>;
|
|
14
|
+
idleReclaim: () => Promise<void>;
|
|
15
|
+
/** Start a cold container before a command needs it — see `./workspace.ts`. */
|
|
16
|
+
containerWarm: () => Promise<void>;
|
|
17
|
+
containerIdle: (payload?: SyncDrainIntent) => Promise<void>;
|
|
18
|
+
syncRetry: (payload?: SyncDrainIntent) => Promise<void>;
|
|
19
|
+
};
|
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* What a workspace object wakes for, as one map.
|
|
3
|
+
*
|
|
4
|
+
* Its own module because the object that registers these callbacks and the
|
|
5
|
+
* `JobLifecycle` in `./install-job.ts` that schedules some of them by name both type
|
|
6
|
+
* against it, and neither should own it. A name that exists in one and not the
|
|
7
|
+
* other is then a compile error rather than a schedule that is rejected at
|
|
8
|
+
* runtime.
|
|
9
|
+
*/
|
|
10
|
+
export {};
|