@polderlabs/bizar-omp 0.2.0 → 0.3.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 +30 -4
- package/agents/bizar-architect.md +1 -1
- package/agents/bizar-docs.md +1 -1
- package/agents/bizar-implementer.md +1 -1
- package/agents/bizar-planner.md +1 -1
- package/agents/bizar-researcher.md +1 -1
- package/agents/bizar-reviewer.md +1 -1
- package/agents/bizar-security-reviewer.md +1 -1
- package/agents/bizar-verifier.md +1 -1
- package/dist/cli/doctor.d.ts +4 -4
- package/dist/cli/install.js +2 -2
- package/dist/extension.d.ts +17 -0
- package/dist/extension.d.ts.map +1 -1
- package/dist/extension.js +60 -12
- package/dist/extension.js.map +1 -1
- package/dist/index.d.ts +1 -0
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +1 -0
- package/dist/index.js.map +1 -1
- package/dist/omp/autonomous-settings.d.ts +0 -5
- package/dist/omp/autonomous-settings.d.ts.map +1 -1
- package/dist/omp/autonomous-settings.js +1 -5
- package/dist/omp/autonomous-settings.js.map +1 -1
- package/dist/omp/compatibility.d.ts +4 -4
- package/dist/omp/compatibility.js +1 -1
- package/dist/omp/config.d.ts.map +1 -1
- package/dist/omp/config.js +2 -1
- package/dist/omp/config.js.map +1 -1
- package/dist/omp/model-role-assignment.d.ts +62 -0
- package/dist/omp/model-role-assignment.d.ts.map +1 -0
- package/dist/omp/model-role-assignment.js +92 -0
- package/dist/omp/model-role-assignment.js.map +1 -0
- package/dist/omp/model-roles.d.ts +11 -3
- package/dist/omp/model-roles.d.ts.map +1 -1
- package/dist/omp/model-roles.js +2 -1
- package/dist/omp/model-roles.js.map +1 -1
- package/docs/compatibility/baseline.json +2 -2
- package/docs/compatibility/phase-0-report.md +1 -1
- package/docs/compatibility/supported-surfaces.json +1 -1
- package/docs/releases/0.3.0.md +9 -0
- package/docs/releases/native-stable.md +1 -1
- package/docs/releases/npm-publishing.md +1 -1
- package/docs/releases/support-matrix.md +1 -1
- package/package.json +2 -1
- package/skills/omp-native-development/SKILL.md +111 -0
- package/skills/omp-native-development/agents/openai.yaml +4 -0
- package/skills/omp-native-development/assets/native-role-pack/agent-names.example.json +8 -0
- package/skills/omp-native-development/assets/native-role-pack/agents/bizar-implementer.md +12 -0
- package/skills/omp-native-development/assets/native-role-pack/agents/bizar-planner.md +12 -0
- package/skills/omp-native-development/assets/native-role-pack/agents/bizar-researcher.md +12 -0
- package/skills/omp-native-development/assets/native-role-pack/agents/bizar-reviewer.md +12 -0
- package/skills/omp-native-development/assets/native-role-pack/agents/bizar-security-reviewer.md +12 -0
- package/skills/omp-native-development/assets/native-role-pack/agents/bizar-verifier.md +12 -0
- package/skills/omp-native-development/assets/native-role-pack/bindings.json +8 -0
- package/skills/omp-native-development/assets/native-role-pack/config.fragment.json +10 -0
- package/skills/omp-native-development/assets/native-role-pack/config.fragment.yml +13 -0
- package/skills/omp-native-development/assets/native-role-probe.ts +37 -0
- package/skills/omp-native-development/assets/tests/acceptance-matrix.json +802 -0
- package/skills/omp-native-development/assets/tests/native-role-contract.test.ts +96 -0
- package/skills/omp-native-development/references/accuracy-and-versioning.md +63 -0
- package/skills/omp-native-development/references/agent-and-model-roles.md +158 -0
- package/skills/omp-native-development/references/bizar-integration-contract.md +100 -0
- package/skills/omp-native-development/references/bundle-validation.json +54 -0
- package/skills/omp-native-development/references/developer-handoff.md +126 -0
- package/skills/omp-native-development/references/execution-and-lifecycle.md +74 -0
- package/skills/omp-native-development/references/extensions-and-packaging.md +82 -0
- package/skills/omp-native-development/references/native-validation-matrix.md +96 -0
- package/skills/omp-native-development/references/official-docs-index.md +174 -0
- package/skills/omp-native-development/references/offline-test-results.txt +43 -0
- package/skills/omp-native-development/references/research-and-test-status.md +31 -0
- package/skills/omp-native-development/references/sessions-sdk-rpc.md +59 -0
- package/skills/omp-native-development/references/settings-providers-security.md +69 -0
- package/skills/omp-native-development/references/source-manifest.json +1359 -0
- package/skills/omp-native-development/references/tools-and-capabilities.md +59 -0
- package/skills/omp-native-development/scripts/audit_role_config.py +167 -0
- package/skills/omp-native-development/scripts/omp_docs.py +252 -0
- package/skills/omp-native-development/scripts/test_tools.py +222 -0
|
@@ -0,0 +1,96 @@
|
|
|
1
|
+
/** Starter source-coupled native tests: NOT RUN in the skill-creation environment.
|
|
2
|
+
* Copy into a project with the qualified @oh-my-pi/pi-coding-agent dependency.
|
|
3
|
+
* Run with Bun. The helpers are native imports, not a duplicate Bizar resolver.
|
|
4
|
+
* These tests do not create sessions or prove provider/child execution behavior.
|
|
5
|
+
*/
|
|
6
|
+
import { describe, expect, test } from "bun:test";
|
|
7
|
+
import {
|
|
8
|
+
expandRoleAlias,
|
|
9
|
+
extractExplicitThinkingSelector,
|
|
10
|
+
resolveAgentAdvisorSelection,
|
|
11
|
+
resolveAgentModelSelection,
|
|
12
|
+
resolveAgentPrewalkPattern,
|
|
13
|
+
resolveExplicitModelRole,
|
|
14
|
+
} from "@oh-my-pi/pi-coding-agent/config/model-resolver";
|
|
15
|
+
import { Settings } from "@oh-my-pi/pi-coding-agent/config/settings";
|
|
16
|
+
|
|
17
|
+
function settings() {
|
|
18
|
+
return Settings.isolated({
|
|
19
|
+
modelRoles: {
|
|
20
|
+
default: "fixture/default",
|
|
21
|
+
task: "fixture/task",
|
|
22
|
+
bizar_build: "fixture/build",
|
|
23
|
+
bizar_review: "fixture/review",
|
|
24
|
+
bizar_outer: "@bizar_review",
|
|
25
|
+
},
|
|
26
|
+
});
|
|
27
|
+
}
|
|
28
|
+
|
|
29
|
+
describe("native Bizar role resolution contracts", () => {
|
|
30
|
+
test("custom role is expanded while identity survives", () => {
|
|
31
|
+
expect(resolveAgentModelSelection({ agentModel: "@bizar_build", settings: settings() }))
|
|
32
|
+
.toEqual({ patterns: ["fixture/build"], role: "bizar_build" });
|
|
33
|
+
});
|
|
34
|
+
test("native agent settings override wins over frontmatter", () => {
|
|
35
|
+
expect(resolveAgentModelSelection({
|
|
36
|
+
settingsOverride: "@bizar_review", agentModel: "@bizar_build", settings: settings(),
|
|
37
|
+
})).toEqual({ patterns: ["fixture/review"], role: "bizar_review" });
|
|
38
|
+
});
|
|
39
|
+
test("internal request override is distinct from public task schema", () => {
|
|
40
|
+
expect(resolveAgentModelSelection({
|
|
41
|
+
requestModel: "@bizar_build", settingsOverride: "@bizar_review", settings: settings(),
|
|
42
|
+
})).toEqual({ patterns: ["fixture/build"], role: "bizar_build" });
|
|
43
|
+
});
|
|
44
|
+
test("empty internal request does not suppress configured override", () => {
|
|
45
|
+
expect(resolveAgentModelSelection({
|
|
46
|
+
requestModel: "", settingsOverride: "@bizar_review", settings: settings(),
|
|
47
|
+
})).toEqual({ patterns: ["fixture/review"], role: "bizar_review" });
|
|
48
|
+
});
|
|
49
|
+
test("custom role aliases can chain", () => {
|
|
50
|
+
expect(resolveAgentModelSelection({ agentModel: "@bizar_outer", settings: settings() }))
|
|
51
|
+
.toEqual({ patterns: ["fixture/review"], role: "bizar_outer" });
|
|
52
|
+
});
|
|
53
|
+
test("legacy aliases preserve role identity", () => {
|
|
54
|
+
expect(resolveAgentModelSelection({ agentModel: "pi/bizar_build", settings: settings() }))
|
|
55
|
+
.toEqual({ patterns: ["fixture/build"], role: "bizar_build" });
|
|
56
|
+
});
|
|
57
|
+
test("singleton default agent selector inherits active session", () => {
|
|
58
|
+
expect(resolveAgentModelSelection({
|
|
59
|
+
agentModel: "@default", activeModelPattern: "fixture/active", settings: settings(),
|
|
60
|
+
})).toEqual({ patterns: ["fixture/active"], role: undefined });
|
|
61
|
+
});
|
|
62
|
+
test("configured task role beats parent fallback for @task agent", () => {
|
|
63
|
+
expect(resolveAgentModelSelection({
|
|
64
|
+
agentModel: "@task", activeModelPattern: "fixture/active", settings: settings(),
|
|
65
|
+
})).toEqual({ patterns: ["fixture/task"], role: "task" });
|
|
66
|
+
});
|
|
67
|
+
test("bare model identity is not an explicit role", () => {
|
|
68
|
+
expect(resolveExplicitModelRole("fixture/build", settings())).toBeUndefined();
|
|
69
|
+
});
|
|
70
|
+
test("explicit outer effort selector is recognized by native parser", () => {
|
|
71
|
+
expect(extractExplicitThinkingSelector("@bizar_review:low", settings())).toBe("low");
|
|
72
|
+
});
|
|
73
|
+
test("alias expansion uses configured custom role", () => {
|
|
74
|
+
expect(expandRoleAlias("@bizar_outer", settings())).toBe("fixture/review");
|
|
75
|
+
});
|
|
76
|
+
test("prewalk default is native smol", () => {
|
|
77
|
+
expect(resolveAgentPrewalkPattern({ agentPrewalk: true })).toBe("@smol");
|
|
78
|
+
});
|
|
79
|
+
test("prewalk override can disable frontmatter opt-in", () => {
|
|
80
|
+
expect(resolveAgentPrewalkPattern({ settingsOverride: "off", agentPrewalk: true })).toBeUndefined();
|
|
81
|
+
});
|
|
82
|
+
test("prewalk on retains explicit agent target", () => {
|
|
83
|
+
expect(resolveAgentPrewalkPattern({ settingsOverride: "on", agentPrewalk: "@bizar_build" }))
|
|
84
|
+
.toBe("@bizar_build");
|
|
85
|
+
});
|
|
86
|
+
test("advisor is absent without opt-in", () => {
|
|
87
|
+
expect(resolveAgentAdvisorSelection({})).toBeUndefined();
|
|
88
|
+
});
|
|
89
|
+
test("advisor settings can disable frontmatter opt-in", () => {
|
|
90
|
+
expect(resolveAgentAdvisorSelection({ settingsOverride: "off", agentAdvisor: true })).toBeUndefined();
|
|
91
|
+
});
|
|
92
|
+
test("advisor on retains explicit agent model pattern", () => {
|
|
93
|
+
expect(resolveAgentAdvisorSelection({ settingsOverride: "on", agentAdvisor: "@bizar_review" }))
|
|
94
|
+
.toEqual({ model: "@bizar_review" });
|
|
95
|
+
});
|
|
96
|
+
});
|
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
# Accuracy, evidence and version qualification
|
|
2
|
+
|
|
3
|
+
## Contents
|
|
4
|
+
1. Scope and confidence
|
|
5
|
+
2. Target fingerprint
|
|
6
|
+
3. Evidence hierarchy
|
|
7
|
+
4. Documentation acquisition
|
|
8
|
+
5. Updating the skill
|
|
9
|
+
6. Source references
|
|
10
|
+
|
|
11
|
+
## Scope and confidence
|
|
12
|
+
|
|
13
|
+
This is an authored engineering skill plus an exhaustive index of the Markdown files in the pinned upstream `docs/` tree. It is not a complete offline copy of the repository, not an implementation of Bizar, and not an assurance that every documented behavior is correct on every installed release.
|
|
14
|
+
|
|
15
|
+
The most detailed audit concerns the native integration contracts: agents, model roles, settings, extensions, task execution, isolation, lifecycle and SDK boundaries. Other documentation is indexed for targeted retrieval. The manifest states which documents were reviewed in ranges and which were indexed only. Do not convert navigation coverage into a claim of exhaustive behavioral testing.
|
|
16
|
+
|
|
17
|
+
Separate five kinds of statement: DOCUMENTED, SOURCE-OBSERVED, TESTED, PROPOSED and UNKNOWN. Documentation describes intended behavior. Source identifies an implementation at a commit. Upstream tests specify expectations but are not proof that those tests passed in the developer's environment. Only an executed test with recorded output earns TESTED.
|
|
18
|
+
|
|
19
|
+
## Target fingerprint
|
|
20
|
+
|
|
21
|
+
Research source: `can1357/oh-my-pi@dbf3afad4894bde827d90f965e77b3fe1c5a95e5`.
|
|
22
|
+
Comparison release: `v18.2.4@1c0303b1f2ec515cbf4b44a9a49d68a029531aac`.
|
|
23
|
+
The source main snapshot is ahead of that release and includes TUI-related changes. Both can present a package version of 18.2.4. Therefore compare artifacts/commits, not just a semver string.
|
|
24
|
+
|
|
25
|
+
Record the installed package name/version, lockfile integrity or binary checksum, source SHA when available, Bun version, OS/architecture, execution mode, profile, agent directory, cwd, project settings and overlays. Include which facts are unavailable. Do not assert an installed binary's source commit solely because its version matches a Git tag.
|
|
26
|
+
|
|
27
|
+
The package's Bun minimum and the monorepo's package-manager/build requirement are different surfaces. Re-read the target package manifest and root toolchain configuration rather than treating one minimum as universal.
|
|
28
|
+
|
|
29
|
+
Pin the published package in the developing project. Qualify the release build first when that is the deployment target. Run a separate canary for upstream main; never silently replace production dependencies with main to make a test pass.
|
|
30
|
+
|
|
31
|
+
## Evidence hierarchy
|
|
32
|
+
|
|
33
|
+
For a concrete behavior, use the target's runtime observations and relevant tests, exported types, implementation callsites, and exact documentation together. None can be mechanically substituted for all others. A declared callback with no callsite is not a functioning integration seam. A wildcard export that permits importing an internal class is not a maintenance guarantee.
|
|
34
|
+
|
|
35
|
+
Prefer immutable repository links with line anchors. Record the file's Git blob SHA or digest where practical. Compare documentation with the actual installed code when they disagree. Preserve a short discrepancy note and regression case, and label the uncertainty rather than choosing the most convenient interpretation.
|
|
36
|
+
|
|
37
|
+
Treat public web pages, model catalogs, release notes and endpoint behavior as time-sensitive. Generic pi-mono documentation, tutorial snippets and forks may describe a different API. Use them only as leads; verify against this repository and revision.
|
|
38
|
+
|
|
39
|
+
For claims beyond these references, retrieve the relevant source instead of extrapolating from a similar tool. When no supporting source or executable environment exists, report UNKNOWN, with the smallest required experiment.
|
|
40
|
+
|
|
41
|
+
## Documentation acquisition
|
|
42
|
+
|
|
43
|
+
`source-manifest.json` contains the pinned paths and expected Git blob identities. `omp_docs.py sync` downloads each file from the exact commit or reads Git objects locally. It validates the bytes against Git's blob hashing format and refuses to overwrite a different existing file. A redirect to HTML, truncated content or stale page will fail hash validation instead of entering the corpus as documentation.
|
|
44
|
+
|
|
45
|
+
The fetcher verifies each selected file. The checked-in manifest covers the root docs Markdown inventory and selected sources; package-local READMEs and additional sources must be retrieved separately as the task requires. It does not crawl random external links or run repository code.
|
|
46
|
+
|
|
47
|
+
The source manifest stores expected upstream identities obtained from GitHub; these are not claims that full files are already present locally. The complete upstream text was not bundled during skill creation because container network access was unavailable. The online fetch path is provided and tested through controlled mocks, not an actual successful network download in this environment.
|
|
48
|
+
|
|
49
|
+
Use `verify` after syncing. A partial corpus must be reported as partial. Literal search emits line-numbered hits, not semantic conclusions; read the surrounding definition and caller before implementing.
|
|
50
|
+
|
|
51
|
+
## Updating the skill
|
|
52
|
+
|
|
53
|
+
Run `drift --repo PATH` against a local checkout to compare tracked paths at HEAD. This only detects changes/deletions in known files; inspect the tree for newly introduced documents and APIs. Do not interpret zero tracked differences as proof that the entire repository is unchanged.
|
|
54
|
+
|
|
55
|
+
For an upgrade, create a new target fingerprint, enumerate its complete docs tree, retrieve changed source/test files, re-run affected native tests, revise the claim register and templates, and only then update the pin. Keep the previous pin available for rollback. Never change the manifest SHA alone while retaining old hashes and asserting compatibility.
|
|
56
|
+
|
|
57
|
+
## Source references
|
|
58
|
+
|
|
59
|
+
- [Research main ref](https://github.com/can1357/oh-my-pi/commit/dbf3afad4894bde827d90f965e77b3fe1c5a95e5)
|
|
60
|
+
- [Comparison release ref](https://github.com/can1357/oh-my-pi/commit/1c0303b1f2ec515cbf4b44a9a49d68a029531aac)
|
|
61
|
+
- [Package manifest](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/packages/coding-agent/package.json)
|
|
62
|
+
- [SDK contract](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/docs/sdk.md)
|
|
63
|
+
- [Porting and divergence](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/docs/porting-from-pi-mono.md)
|
|
@@ -0,0 +1,158 @@
|
|
|
1
|
+
# Native agent and model roles: integration contract
|
|
2
|
+
|
|
3
|
+
Snapshot: `dbf3afad4894bde827d90f965e77b3fe1c5a95e5`. These are version-bound contracts, not provider recommendations. Read the sources at the end when implementing.
|
|
4
|
+
|
|
5
|
+
## Contents
|
|
6
|
+
1. Distinguish identities
|
|
7
|
+
2. Built-in and custom model roles
|
|
8
|
+
3. Agent discovery and definitions
|
|
9
|
+
4. Dispatch and model precedence
|
|
10
|
+
5. Alias, inheritance and selector edge cases
|
|
11
|
+
6. Effort and service tiers
|
|
12
|
+
7. Prewalk, advisors and fallback
|
|
13
|
+
8. Configuration ownership and live changes
|
|
14
|
+
9. Skills, tagged models and Vibe
|
|
15
|
+
10. Bizar implementation requirements
|
|
16
|
+
11. Source references
|
|
17
|
+
|
|
18
|
+
## 1. Distinguish identities
|
|
19
|
+
|
|
20
|
+
An **agent type** is a discovered definition such as `bizar-reviewer`: its instructions, permitted tools, spawn policy and model selector defaults. A **spawned agent ID** identifies one runtime instance and its artifacts. A **model role** is a settings-backed selector such as `bizar_review`, addressed as `@bizar_review`. A **concrete model** is a provider/model identity chosen after native resolution. **Thinking effort** configures reasoning behavior. A **service tier** configures a provider's service treatment. A **transport** describes how requests reach an endpoint.
|
|
21
|
+
|
|
22
|
+
Do not use agent names as model names, service tiers as effort levels, or registry IDs as reusable specialist definitions. Do not conflate the bundled `task` agent, the native `task` tool, and the `task` model role merely because they share a word.
|
|
23
|
+
|
|
24
|
+
## 2. Built-in and custom model roles
|
|
25
|
+
|
|
26
|
+
The source-defined built-ins at this pin are:
|
|
27
|
+
|
|
28
|
+
| Role | Native purpose or interpretation |
|
|
29
|
+
| --- | --- |
|
|
30
|
+
| `default` | Default main-session selection |
|
|
31
|
+
| `smol` | Fast/lightweight selection |
|
|
32
|
+
| `slow` | Stronger/thinking selection |
|
|
33
|
+
| `vision` | Vision-oriented selection |
|
|
34
|
+
| `plan` | Architect/planning selection |
|
|
35
|
+
| `commit` | Commit-oriented selection |
|
|
36
|
+
| `tiny` | Online lightweight background work such as titles, memory and classification |
|
|
37
|
+
| `task` | Subtask selection |
|
|
38
|
+
| `advisor` | Advisor selection |
|
|
39
|
+
|
|
40
|
+
These labels do not themselves guarantee model speed, capability, price, vision, or supported reasoning. Those properties depend on actual resolution and provider behavior. `title` and `designer` are not built-ins in this snapshot; a user could still create custom roles with those names.
|
|
41
|
+
|
|
42
|
+
Custom roles are supported. `modelRoles`, `cycleOrder`, and `modelTags` can contribute known role IDs to UI metadata. However, a display tag or cycle entry alone is not a concrete model assignment. Resolve the role before using it as a required worker dependency.
|
|
43
|
+
|
|
44
|
+
The canonical alias is `@role`; `pi/role` is a supported compatibility spelling. `*` selects the default role. Quote aliases in YAML. A role can refer to another role, including an explicit effort suffix. Do not impose the false rule that all native role mappings must point directly to concrete models.
|
|
45
|
+
|
|
46
|
+
## 3. Agent discovery and definitions
|
|
47
|
+
|
|
48
|
+
Task agents are read from native `.omp` roots and package `agents/` directories. At this pin, the first exact agent name wins in the following order: nearest project `.omp/agents`, user `.omp/agent/agents`, enabled OMP extension-package agent roots (CLI, project settings, user settings, installed packages), supported Claude marketplace plugin roots, then bundled definitions.
|
|
49
|
+
|
|
50
|
+
Direct `.claude/agents`, `.codex/agents`, and `.gemini/agents` roots are intentionally not equivalent to native task-agent definitions. Their frontmatter may mean something different. Names are case-sensitive; directory filenames are sorted before deduplication. Project definitions can legitimately shadow package definitions. Diagnose the effective file/source, rather than assuming a bundled Bizar file won.
|
|
51
|
+
|
|
52
|
+
An agent needs `name` and `description` frontmatter plus a prompt body. Relevant fields include `tools`, `spawns`, prioritized `model`, `thinking-level` or `thinking`, `output`, `blocking`, `autoloadSkills`, `read-summarize`, `prewalk`, and `advisor`. `model` accepts a selector, CSV or an array. `tools` accepts CSV or an array; explicit tools cause `yield` to be added by native parsing.
|
|
53
|
+
|
|
54
|
+
`spawns` may be a wildcard or a list. A legacy convenience maps missing `spawns` plus a `task` tool to wildcard spawn permission. Avoid inadvertently enabling nested delegation in a worker. Do not describe a tools list as a filesystem sandbox.
|
|
55
|
+
|
|
56
|
+
Missing/invalid custom definitions can be skipped with warnings. That is why packaging must test discovery of every expected name, not merely check that files exist. Native bundled agents in this snapshot are `scout`, `reviewer`, `security-reviewer`, `task`, and `sonic`.
|
|
57
|
+
|
|
58
|
+
## 4. Dispatch and model precedence
|
|
59
|
+
|
|
60
|
+
The model-facing task batch uses this form when batch mode is enabled:
|
|
61
|
+
|
|
62
|
+
```json
|
|
63
|
+
{
|
|
64
|
+
"context": "Shared background and references for this batch.",
|
|
65
|
+
"tasks": [
|
|
66
|
+
{
|
|
67
|
+
"agent": "bizar-reviewer",
|
|
68
|
+
"task": "Review the exact candidate revision and report evidence-backed findings."
|
|
69
|
+
}
|
|
70
|
+
]
|
|
71
|
+
}
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
Do not add a public `model` field. Select a native agent whose defaults and configured overrides resolve the desired model policy. In batch mode, `agent` belongs to each item, not the batch envelope. The public eval helper must also be checked separately; an internal `StructuredSubagentRequest.model` field is not proof that the model-facing `agent()` helper accepts it.
|
|
75
|
+
|
|
76
|
+
The ordinary task selection precedence is:
|
|
77
|
+
|
|
78
|
+
1. `task.agentModelOverrides[exactAgentName]`, when it resolves to nonempty configured patterns.
|
|
79
|
+
2. The agent definition's model selector(s), with native inheritance exceptions.
|
|
80
|
+
3. The parent's active selection, its configured fallback, then the native default lookup as applicable.
|
|
81
|
+
|
|
82
|
+
The internal shared selector also accepts a higher-priority request override for callers that actually supply that field. Do not expose or emulate this as a fictional public task parameter.
|
|
83
|
+
|
|
84
|
+
Native task/eval preflight reloads persisted settings and rediscovers agents. Separate create-time descriptions may be cached, so discovery text shown earlier can lag execution-time state. The correct implementation is to preserve the native execution path, not freeze a copy of the picker options in Bizar.
|
|
85
|
+
|
|
86
|
+
## 5. Alias, inheritance and selector edge cases
|
|
87
|
+
|
|
88
|
+
The native resolver returns expanded patterns together with the original explicit role. Preserve both. Deriving the role from the final model identity loses information needed by role-based retry fallback.
|
|
89
|
+
|
|
90
|
+
For source-coupled contract tests, `resolveAgentModelSelection` is the relevant helper; isolate its import behind a pinned test/adapter boundary. Do not duplicate it in Bizar's business logic. Its result includes `patterns` and `role`, and its source selection is made in one operation.
|
|
91
|
+
|
|
92
|
+
Special inheritance matters. A singleton agent model `default`, `@default`, `*`, or `pi/default` participates in session inheritance rather than necessarily forcing a different globally saved default. A singleton `@task`/`pi/task` uses configured task patterns when present; otherwise native fallback can inherit the session. Replacing these with eagerly resolved strings can change semantics.
|
|
93
|
+
|
|
94
|
+
Unconfigured `smol` and `slow` can inherit a configured default before their built-in priority lists. `tiny` falls back through `smol`. `advisor` can use explicitly configured `slow`, but when that is absent it uses the corresponding priority route rather than indiscriminately inheriting the primary. This is not a guarantee of a distinct provider or model family; inspect the actual result for independent review.
|
|
95
|
+
|
|
96
|
+
Explicit effort on an outer role can override inherited role effort. Selectors may contain colon-bearing model IDs and upstream routing. Use native parsing and model metadata, not `split(':')`, `split('@')`, string truncation, or a guessed suffix list.
|
|
97
|
+
|
|
98
|
+
Native role-cycle handling has fallback behavior; it does not universally throw a cycle error. Bizar's static profile linter deliberately rejects explicit cycles as its own configuration-quality policy. Label that error as Bizar policy rather than misdescribing native behavior.
|
|
99
|
+
|
|
100
|
+
## 6. Effort and service tiers
|
|
101
|
+
|
|
102
|
+
When `task.enableEffort` is enabled, a task item can request `lo`, `med`, or `hi`; this surface is absent from the model-facing schema when disabled. The coarse value maps onto the resolved model's supported reasoning ladder and is constrained by `task.maxEffort`. The cap survives retry-fallback switches. Unsupported combinations need a visible error or the documented native fallback for noncontrollable models, not a fabricated effort value.
|
|
103
|
+
|
|
104
|
+
Agent frontmatter thinking defaults, role suffixes, per-item effort and native auto-thinking are distinct inputs. Exercise their precedence with the target resolver/executor tests. A same-model change in effort can still be a meaningful prewalk transition.
|
|
105
|
+
|
|
106
|
+
Service tier is independent. `task.agentServiceTierOverrides[exactAgentName]` overrides `tier.subagent` for the documented task/eval route. `inherit` snapshots the parent's live per-family tier map at spawn. The child resolves the concrete value against its final model family. Unsupported families do not inherit unrelated provider settings; same-family and cross-family fallback behavior differ.
|
|
107
|
+
|
|
108
|
+
Persisted tier state, including an explicitly empty map, matters on revival. Service-tier controls are configuration settings, not native agent frontmatter or task/eval wire fields. Vibe workers use `tier.subagent` rather than this exact task/eval override path at the inspected revision.
|
|
109
|
+
|
|
110
|
+
Never send `priority` everywhere, assume `high` is a service tier, or use a service tier to select a model. Do not inflate cost estimates by conflating effort with premium service pricing.
|
|
111
|
+
|
|
112
|
+
## 7. Prewalk, advisors and fallback
|
|
113
|
+
|
|
114
|
+
`prewalk: true` opts an agent into the native default handoff target `@smol`; a string chooses a target selector. `task.agentPrewalk[name]` can override it with quoted `on`, `off`, or a pattern. The handoff occurs at the native first edit/write boundary. Unavailable targets are skipped by the documented behavior; an exact model-and-effort no-op is skipped, while a same-model effort downgrade is meaningful.
|
|
115
|
+
|
|
116
|
+
`advisor: true` opts the child into `@advisor`; a string can specify a selector. `task.agentAdvisor[name]` takes precedence. Children default to no advisor unless opted in. Preserve native persistence and cleanup; do not add another background review daemon or accidentally enable advisors in every child.
|
|
117
|
+
|
|
118
|
+
Distinguish initial prioritized pattern selection, authentication fallback, API-error retry fallback, context promotion and prewalk. They are not one interchangeable fallback list. Native auth-aware resolution can use the parent's model when an intended worker model lacks usable credentials; keyless local providers use a sentinel and must not be mistaken for unauthenticated remote services.
|
|
119
|
+
|
|
120
|
+
Record actual `resolvedModel`, fallback indicators and subsequent model changes. A required local-only or approved-provider contract must detect a prohibited effective model before execution through a tested admission seam; merely documenting the fallback after sensitive data was sent is insufficient. Do not claim Bizar has such an enforcement seam until the relevant native path is qualified.
|
|
121
|
+
|
|
122
|
+
Native retry chains may be keyed by the originating role. Context promotion instead consults explicit model metadata and uses temporary switching without rewriting saved role assignments. Gateway retries and OMP retries are separate layers: cap and observe them rather than multiplying unbounded retries.
|
|
123
|
+
|
|
124
|
+
## 8. Configuration ownership and live changes
|
|
125
|
+
|
|
126
|
+
Use `modelRoles` in native settings, not a Bizar replacement router. Preserve `task.agentModelOverrides`, role tags, cycle order and native role storage. Ordinary `omp config set/reset` writes global settings; the model selector can save role assignments to project config when `modelRoleStorage: project`. Do not assume a command launched in a repository writes project-local settings.
|
|
127
|
+
|
|
128
|
+
Global, project, explicit overlays and runtime overrides participate in native precedence. Objects deep-merge; arrays replace. Project settings discovery is cwd-local, unlike nearest-project agent discovery. Profiles and relocated agent directories change the effective global path.
|
|
129
|
+
|
|
130
|
+
If an operator changes a role during a live session, native subsequent dispatch should reflect the new configuration. Bizar can record a settings revision and require re-admission when reproducibility demands it, but it must not secretly overwrite the operator's change or claim the old plan froze native settings.
|
|
131
|
+
|
|
132
|
+
## 9. Skills, tagged models and Vibe
|
|
133
|
+
|
|
134
|
+
A developing agent can specify `autoloadSkills: [omp-native-development]`. Native autoloading refers to the parent's discovered skills. Unknown names are ignored, so validate actual discovery and child injection. Do not assume a YAML entry alone proves this skill reached the child.
|
|
135
|
+
|
|
136
|
+
Composer-tagged models receive session/branch-local pseudonyms such as `m1`. They use the generic task template, not an arbitrary Bizar specialist. They survive supported session resume behavior but are not global identifiers; rewinding can change their registration. Honor explicit user model tagging without silently replacing the requested model with a specialist default.
|
|
137
|
+
|
|
138
|
+
Vibe `fast` routes through bundled `sonic`; `good` routes through bundled `task`. Native `task.agentModelOverrides` and role-backed selectors participate. Verify this separately from task/eval service-tier behavior. Do not override those global bundled agents merely to install Bizar's specialist pack.
|
|
139
|
+
|
|
140
|
+
## 10. Bizar implementation requirements
|
|
141
|
+
|
|
142
|
+
Ship namespaced agents and an opt-in, merge-only configuration example. The example role graph may alias existing native roles (`bizar_build -> @task`, `bizar_review -> @slow`) without selecting a new vendor. Do not install concrete models, provider endpoints or premium tiers automatically.
|
|
143
|
+
|
|
144
|
+
Expose requested agent, source definition, requested role, winning selector source, actual model, reasoning, service tier and fallback/prewalk transitions in diagnostics. Mark unavailable details UNKNOWN; never infer OAuth account identities or sensitive metadata from debug logs.
|
|
145
|
+
|
|
146
|
+
Use static lint for shape/cycles/placeholders, native resolver probes for actual role resolution, and real child execution receipts for effective worker routing. All three layers are necessary. The supplied probes do not by themselves prove the entire integration works.
|
|
147
|
+
|
|
148
|
+
## 11. Source references
|
|
149
|
+
|
|
150
|
+
- [Agent definitions, discovery and routing](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/docs/task-agent-discovery.md)
|
|
151
|
+
- [Built-in role definitions](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/packages/coding-agent/src/config/model-roles.ts)
|
|
152
|
+
- [Model selector implementation, including inheritance and role identity](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/packages/coding-agent/src/config/model-resolver.ts#L970-L1570)
|
|
153
|
+
- [Native resolver tests](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/packages/coding-agent/test/model-resolver.test.ts)
|
|
154
|
+
- [Model configuration and authentication](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/docs/models.md)
|
|
155
|
+
- [Settings, role storage, thinking and tiers](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/docs/settings.md)
|
|
156
|
+
- [Task/eval shared policy implementation](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/packages/coding-agent/src/task/structured-subagent.ts)
|
|
157
|
+
- [Retry behavior and settlement](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/docs/non-compaction-retry-policy.md)
|
|
158
|
+
- [Skills and child autoloading](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/docs/skills.md)
|
|
@@ -0,0 +1,100 @@
|
|
|
1
|
+
# BizarHarness: agent and model-role integration addendum
|
|
2
|
+
|
|
3
|
+
Date: 2026-09-17. This extends the BizarHarness OMP-native rewrite plan. All architecture and acceptance requirements here are PROPOSED until implemented and tested. Native behavior references are pinned to `dbf3afad4894bde827d90f965e77b3fe1c5a95e5`.
|
|
4
|
+
|
|
5
|
+
## Contents
|
|
6
|
+
1. Architectural decision
|
|
7
|
+
2. Semantic agent and model roles
|
|
8
|
+
3. Configuration contract
|
|
9
|
+
4. Dispatch and observation
|
|
10
|
+
5. Effective model changes
|
|
11
|
+
6. Engineering work packages
|
|
12
|
+
7. Release gates
|
|
13
|
+
8. Source references
|
|
14
|
+
|
|
15
|
+
## 1. Architectural decision
|
|
16
|
+
|
|
17
|
+
Bizar must be a native OMP extension and workflow/evidence layer. It must not implement a competing model picker, hard-coded gateway router, worker registry, credential store or job lifecycle. OMP owns native resolution and execution. Bizar adds task scope, acceptance criteria, evidence requirements and integration policy.
|
|
18
|
+
|
|
19
|
+
Agent roles and model roles must remain independently configurable. An operator must be able to change the model behind a specialist without editing its prompt, changing the workflow definition, or bypassing OMP's native override precedence. Installing Bizar must not replace an operator's main model or remap unrelated bundled agents.
|
|
20
|
+
|
|
21
|
+
The default main OMP session performs coordination. Do not add a mandatory nested coordinator for every prompt. Delegate when specialization, independent review, isolation or useful parallelism justifies it.
|
|
22
|
+
|
|
23
|
+
## 2. Semantic agent and model roles
|
|
24
|
+
|
|
25
|
+
Use namespaced specialist definitions and role names. The following is a proposed starting profile, not a native built-in roster:
|
|
26
|
+
|
|
27
|
+
| Bizar agent | Requested model role | Optional default alias | Purpose |
|
|
28
|
+
| --- | --- | --- | --- |
|
|
29
|
+
| `bizar-researcher` | `@bizar_research` | `@plan` | Evidence-grounded investigation and specification |
|
|
30
|
+
| `bizar-planner` | `@bizar_plan` | `@plan` | Dependencies, scope and acceptance criteria |
|
|
31
|
+
| `bizar-implementer` | `@bizar_build` | `@task` | Focused implementation in the assigned workspace |
|
|
32
|
+
| `bizar-reviewer` | `@bizar_review` | `@slow` | Independent correctness review of exact candidate changes |
|
|
33
|
+
| `bizar-security-reviewer` | `@bizar_security` | `@slow` | Threat- and evidence-driven security review when warranted |
|
|
34
|
+
| `bizar-verifier` | `@bizar_verify` | `@task` | Reproducible verification receipts |
|
|
35
|
+
|
|
36
|
+
Default aliases intentionally reuse native operator choices. They do not promise a specific capability, speed, cost or independent model family. Let operators assign concrete provider/model selectors through native configuration. A requirement for independent model-family review needs actual resolved-family checks and explicit behavior when no suitable alternative is available.
|
|
37
|
+
|
|
38
|
+
Keep existing user-specific model tiers as migration inputs, not runtime API assumptions. Legacy Claude aliases can be translated into proposed native mappings during an explicit migration. Do not globally redefine `smol`, `slow`, `task`, `default`, or `advisor` without a requested and displayed configuration change.
|
|
39
|
+
|
|
40
|
+
## 3. Configuration contract
|
|
41
|
+
|
|
42
|
+
Ship an example fragment, not an automatically applied replacement configuration. Merge missing Bizar mappings only after inspection and explicit setup. Preserve any existing Bizar mapping and each exact-name `task.agentModelOverrides` entry. Preserve `modelTags`, `cycleOrder`, enabled model scope, disabled providers, role storage, thinking settings, service tiers, prewalk and advisor settings.
|
|
43
|
+
|
|
44
|
+
Use ordinary native settings for role-to-model selection. Bizar's own configuration should concern workflows, evidence and admission constraints, not a second copy of OMP's model registry. Missing required mappings or conflicting strict constraints produce a clear diagnostic. They must not cause silent fallback to an arbitrarily chosen Bizar model.
|
|
45
|
+
|
|
46
|
+
Keep project/global/profile behavior explicit. A schema-aware setup process must show the target file, existing value, proposed value and rollback record. Ordinary native settings commands are not a general project-local writer. Test profile relocation, cwd-local project settings and array replacement behavior.
|
|
47
|
+
|
|
48
|
+
Run static profile lint, then native role resolution, then an actual child routing test. Only the last establishes the model that a spawned specialist really used. The configured role alone is not authoritative evidence of execution.
|
|
49
|
+
|
|
50
|
+
## 4. Dispatch and observation
|
|
51
|
+
|
|
52
|
+
Native task payloads identify the specialist by `agent`; do not send nonexistent per-task model fields. Use exact names and inspect which source definition won native discovery. Preserve native parent spawn/depth restrictions and skill autoload behavior.
|
|
53
|
+
|
|
54
|
+
Record the following when observable from supported interfaces: run/task ID, native spawned ID, agent name and source, settings revision, requested role, winning override source, resolved provider/model, effective reasoning selector, service tier, fallback flags, native job status, output schema, artifact references and final verification outcome. Mark unobservable fields UNKNOWN; do not fabricate them from prompt text.
|
|
55
|
+
|
|
56
|
+
The settings/profile snapshot must be sanitized. Never persist API keys, OAuth refresh/access tokens, credential commands' output or full request headers into workflow evidence. Do not record provider-family tokens as permanent identifiers when native APIs document them as opaque comparison values.
|
|
57
|
+
|
|
58
|
+
Native preflight refreshes settings and agent definitions. To require reproducible selection, store an expected configuration revision and re-admit if it changed; do not bypass native refresh by using stale Bizar caches. UI role changes must affect subsequent native dispatch or produce an explicit strict-profile conflict, never be silently ignored.
|
|
59
|
+
|
|
60
|
+
## 5. Effective model changes
|
|
61
|
+
|
|
62
|
+
Treat model changes as first-class execution events. Initial role expansion, authentication fallback, per-role API retry fallback, context promotion and prewalk are distinct transitions. Preserve original role identity for fallback chains and final effective identity for evidence.
|
|
63
|
+
|
|
64
|
+
For ordinary autonomy, allow supported native transitions and make them visible. For an explicit local-only, approved-provider, minimum-context or capability requirement, validate the actual effective target before data leaves the permitted boundary. An after-the-fact log cannot enforce a pre-execution privacy restriction. Until all relevant task/eval paths expose qualified admission, label that strict profile unsupported rather than claim universal enforcement.
|
|
65
|
+
|
|
66
|
+
Service-tier and thinking changes must also be tracked separately. A provider-family fallback cannot inherit an unrelated family's tier. A prewalk to the same model with different effort is still a meaningful transition. Advisor opt-in must remain opt-in and must survive native resume behavior correctly.
|
|
67
|
+
|
|
68
|
+
Do not disable native eval/code mode, model switching, prewalk, advisors or tagged-model selection merely because they complicate the harness. Implement parity, explicitly scope a supported profile, or propose a narrow upstream integration seam with tests.
|
|
69
|
+
|
|
70
|
+
## 6. Engineering work packages
|
|
71
|
+
|
|
72
|
+
**ROLE-01: Inventory and schema qualification.** Enumerate current Bizar agents and map them to native specialist definitions. Read the exact target's model-role resolver, agent discovery, settings schema and task/eval bridge. Produce an effective-source report and a source-versus-release compatibility decision.
|
|
73
|
+
|
|
74
|
+
**ROLE-02: Native role profile and discovery.** Add the namespaced agent pack and an opt-in role fragment. Implement merge-only setup and source-aware diagnosis. Test global/project/profile precedence, custom role chains, aliases, agent shadowing and skill discovery.
|
|
75
|
+
|
|
76
|
+
**ROLE-03: Dispatch adapter.** Keep native task execution and role selection. Isolate any source-coupled imports. Prove access to lifecycle and settled result data without interpreting text acknowledgements as completion. Cover flat/batch, sync/async and the supported eval paths.
|
|
77
|
+
|
|
78
|
+
**ROLE-04: Selection provenance.** Record requested role and actual model, plus effectful transitions. Expose a read-only route explanation. Do not create a picker that shadows the native model UI. Build an explicit UNKNOWN path for metadata that the host does not expose.
|
|
79
|
+
|
|
80
|
+
**ROLE-05: Dynamic controls.** Qualify effort caps, prewalk, advisors, role-specific retry fallback, service tiers, provider disabling, context promotion and user-tagged models. Add strict-profile admission only where the relevant pre-execution boundary is proven.
|
|
81
|
+
|
|
82
|
+
**ROLE-06: Qualification and documentation.** Implement all applicable cases in the validation matrix. Run a mocked provider suite and opt-in live gateway/provider smoke tests. Publish a tested version matrix and regenerate role/agent documentation from canonical definitions rather than maintaining contradictory prose.
|
|
83
|
+
|
|
84
|
+
## 7. Release gates
|
|
85
|
+
|
|
86
|
+
A release is not role-native merely because a role string appears in frontmatter. Require evidence that the intended specialist was discovered, the operator override won, the intended role resolved, the real child used the expected target, supported transitions retained provenance, configuration remained unchanged unless explicitly requested, and unsupported combinations failed visibly.
|
|
87
|
+
|
|
88
|
+
Require task/eval isolation-application parity for managed writers. Require actual settlement before verification/integration. Require stale evidence invalidation after changes. Require cancellation/resume and multi-session tests that demonstrate no model, role or state leakage.
|
|
89
|
+
|
|
90
|
+
This addendum and its asset templates are design inputs for the developing agent. They do not constitute a implemented Bizar release or successful runtime qualification.
|
|
91
|
+
|
|
92
|
+
## 8. Source references
|
|
93
|
+
|
|
94
|
+
- [Native roles and discovery](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/docs/task-agent-discovery.md)
|
|
95
|
+
- [Model-role source](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/packages/coding-agent/src/config/model-roles.ts)
|
|
96
|
+
- [Native resolver source](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/packages/coding-agent/src/config/model-resolver.ts)
|
|
97
|
+
- [Settings and native role persistence](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/docs/settings.md)
|
|
98
|
+
- [Extension API](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/docs/extensions.md)
|
|
99
|
+
- [Task contract](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/docs/tools/task.md)
|
|
100
|
+
- [Shared subagent policy](https://github.com/can1357/oh-my-pi/blob/dbf3afad4894bde827d90f965e77b3fe1c5a95e5/packages/coding-agent/src/task/structured-subagent.ts)
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
{
|
|
2
|
+
"created": "2026-09-17",
|
|
3
|
+
"checks": {
|
|
4
|
+
"skill_frontmatter_and_size": "PASS",
|
|
5
|
+
"json_and_yaml_syntax": "PASS",
|
|
6
|
+
"authored_relative_markdown_links": {
|
|
7
|
+
"status": "PASS",
|
|
8
|
+
"checked": 17
|
|
9
|
+
},
|
|
10
|
+
"source_pin_schema": {
|
|
11
|
+
"status": "PASS",
|
|
12
|
+
"upstream_file_bytes_verified_here": false
|
|
13
|
+
},
|
|
14
|
+
"agent_template_bindings": {
|
|
15
|
+
"status": "PASS",
|
|
16
|
+
"agents": 6,
|
|
17
|
+
"native_discovery_tested": false
|
|
18
|
+
},
|
|
19
|
+
"acceptance_case_manifest": {
|
|
20
|
+
"status": "PASS",
|
|
21
|
+
"cases": 59,
|
|
22
|
+
"executed": 0
|
|
23
|
+
},
|
|
24
|
+
"offline_python_tests": {
|
|
25
|
+
"status": "PASS",
|
|
26
|
+
"tests": 36,
|
|
27
|
+
"live_network_tested": false,
|
|
28
|
+
"local_git_fixture_tested": true
|
|
29
|
+
},
|
|
30
|
+
"typescript_syntax_only": {
|
|
31
|
+
"status": "PASS",
|
|
32
|
+
"files": 2,
|
|
33
|
+
"typescript": "5.8.3",
|
|
34
|
+
"scope": "syntax-only; not native typecheck or execution"
|
|
35
|
+
},
|
|
36
|
+
"native_bun_omp_tests": {
|
|
37
|
+
"status": "NOT_RUN",
|
|
38
|
+
"reason": "Bun and qualified OMP runtime/dependencies unavailable",
|
|
39
|
+
"starter_test_cases": 17
|
|
40
|
+
},
|
|
41
|
+
"archive_structure_and_crc": {
|
|
42
|
+
"status": "PASS",
|
|
43
|
+
"root": "omp-native-development",
|
|
44
|
+
"files": 33,
|
|
45
|
+
"unsafe_entries": 0,
|
|
46
|
+
"bytecode_artifacts": 0
|
|
47
|
+
}
|
|
48
|
+
},
|
|
49
|
+
"limitations": [
|
|
50
|
+
"No complete upstream raw-text mirror is bundled.",
|
|
51
|
+
"No live OMP/provider/Bizar workflow was tested.",
|
|
52
|
+
"Passing syntax and helper utilities is not runtime compatibility."
|
|
53
|
+
]
|
|
54
|
+
}
|
|
@@ -0,0 +1,126 @@
|
|
|
1
|
+
# Installation and developing-agent handoff
|
|
2
|
+
|
|
3
|
+
## Contents
|
|
4
|
+
1. Portable use
|
|
5
|
+
2. Native OMP installation
|
|
6
|
+
3. Native developing-agent autoload
|
|
7
|
+
4. Verification commands
|
|
8
|
+
5. Handoff prompt
|
|
9
|
+
6. Do not confuse examples with a release
|
|
10
|
+
|
|
11
|
+
## 1. Portable use
|
|
12
|
+
|
|
13
|
+
Give the developing agent the entire `omp-native-development` directory, not just SKILL.md. The entrypoint links the detailed references, source manifest, examples and validation utilities. Other skill-capable coding agents can read the same entrypoint and relative files; their own skill installation location is host-specific.
|
|
14
|
+
|
|
15
|
+
The skill is passive reference/procedure content. It is not the rebuilt Bizar extension and does not modify OMP on its own. A model can still make mistakes; the skill requires source checks and executable validation instead of declaring its knowledge infallible.
|
|
16
|
+
|
|
17
|
+
## 2. Native OMP installation
|
|
18
|
+
|
|
19
|
+
For one project, put the directory at:
|
|
20
|
+
|
|
21
|
+
```text
|
|
22
|
+
<repository>/.omp/skills/omp-native-development/SKILL.md
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
Keep `references/`, `scripts/`, `assets/`, and `agents/` inside that same skill directory. Do not add an extra nested grouping layer under `skills/`. If another copy already exists, inspect/backup it before replacing it; do not blindly merge old and new knowledge files.
|
|
26
|
+
|
|
27
|
+
With native skill commands enabled, invoke:
|
|
28
|
+
|
|
29
|
+
```text
|
|
30
|
+
/skill:omp-native-development Audit the native agent and model-role integration before implementing the Bizar rewrite.
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
Alternatively the developing agent can read `skill://omp-native-development`. Native capability/source filters can suppress discovery, so verify the skill appears in the actual session. See the pinned `docs/skills.md` for profile/user roots and filtering rather than guessing a global path.
|
|
34
|
+
|
|
35
|
+
The ZIP is not an executable plugin package. Do not use a made-up `omp install skill.zip` command.
|
|
36
|
+
|
|
37
|
+
## 3. Native developing-agent autoload
|
|
38
|
+
|
|
39
|
+
For an existing native developing-agent definition, merge this field into its own frontmatter:
|
|
40
|
+
|
|
41
|
+
```yaml
|
|
42
|
+
autoloadSkills:
|
|
43
|
+
- omp-native-development
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
Preserve its existing skills. This refers to the parent's discovered list; unknown names are ignored by native autoload. Prove a spawned child received the skill before relying on it.
|
|
47
|
+
|
|
48
|
+
`assets/native-role-pack/agents/` contains six proposed Bizar agent templates. They are deliberately examples, not automatically activated definitions. Their aliases depend on optional native settings in `config.fragment.yml`. Merge those only during explicit Bizar setup, preserving existing mappings and overrides.
|
|
49
|
+
|
|
50
|
+
## 4. Verification commands
|
|
51
|
+
|
|
52
|
+
Run native settings inspection from the intended repository root/profile, NOT from inside this skill directory: cwd influences project settings.
|
|
53
|
+
|
|
54
|
+
```sh
|
|
55
|
+
# From the intended repository root; inspect/redact exports before sharing them.
|
|
56
|
+
omp config list --json > /tmp/omp-effective-config.json
|
|
57
|
+
python3 .omp/skills/omp-native-development/scripts/audit_role_config.py \
|
|
58
|
+
/tmp/omp-effective-config.json
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
For the proposed Bizar profile, add `--required-role bizar_build --required-role bizar_review` after the fragment has actually been merged. Supply `--known-agents PATH.json` only with a JSON array of names from real native discovery; `agent-names.example.json` is a fixture, not discovery evidence.
|
|
62
|
+
|
|
63
|
+
Run the skill's offline utility tests:
|
|
64
|
+
|
|
65
|
+
```sh
|
|
66
|
+
python3 -m unittest discover \
|
|
67
|
+
-s .omp/skills/omp-native-development/scripts -p test_tools.py -v
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
Populate references from an already available checkout containing the pinned commit:
|
|
71
|
+
|
|
72
|
+
```sh
|
|
73
|
+
python3 .omp/skills/omp-native-development/scripts/omp_docs.py sync \
|
|
74
|
+
--repo /absolute/path/to/oh-my-pi \
|
|
75
|
+
--out /absolute/path/to/omp-reference
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
Omit `--repo` to fetch exact pinned files over HTTPS. This downloads reference data only, not packages or executables. Verify the resulting corpus with `verify --root PATH`.
|
|
79
|
+
|
|
80
|
+
In a Bun development project with the version-qualified OMP dependency available, run the supplied native helper tests:
|
|
81
|
+
|
|
82
|
+
```sh
|
|
83
|
+
bun test .omp/skills/omp-native-development/assets/tests/native-role-contract.test.ts
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
These are source-coupled starter tests. Adjust only after checking the real target APIs; do not weaken assertions to hide a contract change. The broader acceptance matrix still needs implementation and execution.
|
|
87
|
+
|
|
88
|
+
The optional `assets/native-role-probe.ts` extension can be loaded explicitly using the target's `-e` support. Its `/omp-role-probe` command reports current-session resolution of requested roles. It does not test agent-specific override precedence or live child execution; complete those separately.
|
|
89
|
+
|
|
90
|
+
## 5. Handoff prompt
|
|
91
|
+
|
|
92
|
+
```text
|
|
93
|
+
Read omp-native-development/SKILL.md and follow its source-verification workflow.
|
|
94
|
+
|
|
95
|
+
You are implementing the BizarHarness OMP-native rewrite. Treat the existing rewrite
|
|
96
|
+
plan as the product design, and references/bizar-integration-contract.md as the
|
|
97
|
+
additional mandatory agent/model-role contract. Neither document proves an API exists.
|
|
98
|
+
|
|
99
|
+
First fingerprint the exact OMP target and inspect its native agent discovery,
|
|
100
|
+
model-role resolver, settings precedence, extension APIs and task/eval lifecycle.
|
|
101
|
+
Read references/agent-and-model-roles.md before changing routing. Retrieve exact
|
|
102
|
+
primary docs/source through the pinned manifest or the actual target checkout.
|
|
103
|
+
|
|
104
|
+
Preserve native custom roles, task.agentModelOverrides, model-role storage, tags,
|
|
105
|
+
cycle order, effort, service tiers, prewalk, advisors, native fallback and user
|
|
106
|
+
model selection. Keep requested role and actual effective model separately.
|
|
107
|
+
Never add nonexistent public task parameters or a competing Bizar model router.
|
|
108
|
+
|
|
109
|
+
Implement source/type tests and the relevant cases in assets/tests/acceptance-matrix.json
|
|
110
|
+
before claiming the integration works. Start with one actual discovered specialist,
|
|
111
|
+
prove its operator override and role routing in a child session, then exercise
|
|
112
|
+
async settlement, capture-only isolation, cancellation/resume and verification.
|
|
113
|
+
|
|
114
|
+
Do not modify global credentials/configuration, publish, push, deploy, or erase
|
|
115
|
+
legacy state unless explicitly authorized for the implementation task. Distinguish
|
|
116
|
+
DOCUMENTED, SOURCE-OBSERVED, TESTED, PROPOSED and UNKNOWN claims. Report exact tests
|
|
117
|
+
actually run and do not label any unrun check as passing.
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
Change the first path to the actual location of the skill directory. The prompt must travel with the entire directory or with access to its references.
|
|
121
|
+
|
|
122
|
+
## 6. Do not confuse examples with a release
|
|
123
|
+
|
|
124
|
+
The skill is packaged and its offline utilities were tested. The rebuilt Bizar system has not been implemented by this skill-creation task. Native Bun tests, OMP installation/probe behavior, provider connectivity, and full end-to-end integration still require execution in the developer's environment.
|
|
125
|
+
|
|
126
|
+
Sources: the pinned `docs/skills.md`, `docs/task-agent-discovery.md`, `docs/settings.md`, `docs/extensions.md`, and `docs/cli-reference.md`, linked in the official documentation index.
|