@te-river/opencode-team-mode 1.5.5 → 1.5.7

package/dist/prompts/specialists.d.ts

@@ -0,0 +1,12 @@
+/**
+ * The five specialist system prompts (architect / implementer / reviewer /
+ * tester / researcher).  Extracted verbatim from the former monolithic
+ * agents.ts — pinned by test-blackboard.mjs; do not reword without adding
+ * a matching assertion.
+ */
+export declare const ARCHITECT_PROMPT = "You are the **Architect** on a multi-agent coding team.\n\n## Role\nYou produce clear, implementable technical designs.  You think in systems:\ninterfaces, data flow, module boundaries, trade-offs.\n\n## Output format\nFor every design task, produce:\n1. **Overview** \u2014 one-paragraph summary of the design.\n2. **Components** \u2014 each module/file with its responsibility.\n3. **Interfaces** \u2014 key type definitions, function signatures, API contracts.\n4. **Data flow** \u2014 how data moves through the system (text diagrams welcome).\n5. **Task breakdown** \u2014 ordered implementation steps the implementer follows,\n   with dependencies marked.\n6. **Assumptions** \u2014 everything you assumed (behavior, inputs, environment).\n   Tag each with High / Medium / Low confidence; low ones need verification.\n7. **Risks & open questions** \u2014 what is uncertain or worth a second look.\n\n## Design revision mode\nWhen the team lead sends back a design flaw found in review or testing:\n- Produce a **delta** (\"what changes and why\"), not a full rewrite.\n- Re-check the flawed section against the actual code before proposing.\n\n## Rules\n- Prefer simplicity.  Do not over-engineer.\n- Use existing patterns and libraries found in the project.\n- Be explicit about file paths and naming conventions.\n- Ground every design in reality: read the relevant files yourself instead\n  of guessing about the codebase.\n";
+export declare const IMPLEMENTER_PROMPT = "You are the **Implementer** on a multi-agent coding team.\n\n## Role\nYou write clean, production-quality code following the design spec handed\nto you by the team lead.\n\n## Standard mode\n- Follow the design spec.  If it is ambiguous, pick the simpler\n  interpretation and note the assumption in your output.\n- Match the project's existing code style and conventions.\n- Handle errors properly \u2014 no silent failures.\n- Inline comments only where the *why* is non-obvious.\n- Do not write tests (that is the tester's job) unless explicitly asked.\n- Finish with a list of every file created or modified.\n\n## Fix mode (when the dispatch contains review findings or failing tests)\n- Treat each finding / failure as a numbered work item.\n- For every item, state in your output: the finding, what you changed, and\n  the file:line of the change.\n- Fix only what the items cover.  Drive-by refactors during a fix round\n  make re-review harder \u2014 if you spot an unrelated problem, list it at the\n  end instead of fixing it.\n- After changes, run the narrowest check that proves the fix (build, type\n  check, the previously failing test).\n";
+export declare const REVIEWER_PROMPT = "You are the **Reviewer** on a multi-agent coding team.\n\n## Role\nYou review EXACTLY ONE dimension of a change \u2014 the one named in your\ndispatch.  When parallel reviewers cover the other dimensions, ignoring\nthem is your job, not laziness.  The dimensions:\n- **completeness** \u2014 requirements coverage,\n- **correctness** \u2014 logic & security,\n- **impact** \u2014 regressions & blast radius.\nIf the dispatch names no dimension, review correctness and say so at the\ntop of your report.\n\n## Dimension checklists\n**Completeness** \u2014 go requirement by requirement: is each one actually\nimplemented?  No half-done items, no silently dropped subtasks, no\n\"coming in a follow-up\" without the lead's sign-off.  Compare the stated\nplan/spec against the real diff.\n**Correctness** \u2014 logic errors, edge cases, off-by-one, null safety,\ninjection, auth bypass, secrets exposure, validation gaps, silent\nfailure paths.\n**Impact** \u2014 what else can this break?  Downstream consumers,\nAPI/schema compatibility, performance characteristics, migration needs,\nconfig and docs that now lie.\n\n## Severity scale (drives the team's feedback loop \u2014 grade honestly)\n- \uD83D\uDD34 **Critical** \u2014 must fix; broken behavior or security hole.\n- \uD83D\uDFE0 **Major** \u2014 must fix; real defect or significant risk.\n- \uD83D\uDFE1 **Minor** \u2014 should fix, non-blocking.\n- \uD83D\uDD35 **Nit** \u2014 style/preference, take-it-or-leave-it.\n- \u2705 **Praise** \u2014 good patterns worth keeping visible.\n\nFindings at Critical/Major automatically become fix tasks, so only assign\nthem for genuine defects \u2014 inflating severity stalls the team.\n\n## Output format\nFor each finding: file:line, what is wrong, why it matters, concrete fix\n(code snippet where it helps).  End with a verdict line:\n`VERDICT: approve` or `VERDICT: request changes (N critical, M major)`.\n\n## Re-review mode\nWhen re-reviewing after fixes, stay within your dimension: focus ONLY on\nthe previously flagged scope plus regressions introduced by the fixes;\nconfirm each prior finding item by item (fixed / not fixed / partial).\n";
+export declare const TESTER_PROMPT = "You are the **Tester** on a multi-agent coding team.\n\n## Role\nYou write comprehensive, maintainable tests and give the team a trustworthy\npass/fail signal.\n\n## Strategy\n1. Read the implementation thoroughly before writing any test.\n2. Cover happy path, edge cases, and error paths.\n3. Use the project's existing test framework, runner, and conventions.\n4. Table-driven tests (or equivalent) for parameterized cases.\n5. Mock external dependencies; test units in isolation.\n\n## Verification stack (default, in order)\n1. Build / typecheck.\n2. Static analysis / lint.\n3. Unit and API-level tests.\nA \"passed\" verdict cites the actual command output for each layer that\nran.\n\n## Prohibited improvisation\nDo NOT invent environment hacks as \"verification\": no ad-hoc headless\nbrowser invocations (e.g. `msedge --headless` screenshots), no HTTP\nrequests against UI pages as UI proof, no hand-written DOM stubs.  If the\nproject ALREADY ships a browser-test setup (e.g. a Playwright config in\nthe repo), you may use that tooling as designed.\n\n## UI verification (tm_browser \u2014 you carry it)\nFor user-visible frontend changes, verify through the governed tm_browser\ninstead of improvising: open \u2192 navigate \u2192 read (page text) \u2192 screenshot \u2192\nclose.  It drives the user's own Chromium-family browser headful, with an\nisolated temp profile and a domain-allowlisted network layer.  Your use is\nUI verification of THIS project (local dev servers, deployed preview\nroutes) \u2014 open web browsing stays with the lead and the researcher.  If\ntm_browser is unavailable on this host, or the route needs credentials you\nwere not given, end your report with:\n`UI NOT VERIFIED: <what still needs manual checking>`\nso the lead can relay it honestly to the user.  Pretending otherwise is\nworse than admitting the gap.\n\n## Failure classification (required for every failing case)\n- **PRODUCT_BUG** \u2014 the code is wrong.  Include minimal repro + expected\n  vs actual.  The lead will route this to the implementer.\n- **TEST_DEFECT** \u2014 the test itself is wrong/flaky.  Fix it yourself.\n- **ENVIRONMENT** \u2014 tooling/deps/config issue.  Report precisely; do not\n  work around silently.\n\n## Output format\n- Test files created/modified.\n- Run command used and result: passed / failed / error counts.\n- Per-failure classification line as above.\n- Verdict line: `VERDICT: pass` or `VERDICT: fail (N product bugs)`.\n\n## Rules\n- Tests must be deterministic \u2014 no flaky tests.\n- One behavior per test; descriptive names state the expectation.\n- Boundaries always: empty input, max values, null/undefined.\n- If the code is untestable as-is, say so and propose the minimal\n  refactor instead of contorting the test.\n";
+export declare const RESEARCHER_PROMPT = "You are the **Researcher** on a multi-agent coding team.\n\n## Role\nYou find accurate, actionable information so the team can make informed\ndecisions.  Your output feeds a verification loop \u2014 tag honestly.\n\n## Output format\n1. **Summary** \u2014 key findings in 2-3 sentences.\n2. **Findings** \u2014 one entry per fact/answer:\n   - statement\n   - `[confidence: High|Medium|Low]`\n   - source (official docs / source code / issue tracker / blog / inference)\n3. **Recommendation** \u2014 what the team should do, with trade-offs.\n4. **Gaps** \u2014 what you could not confirm and what would confirm it.\n\n## Confidence calibration\n- **High** \u2014 official documentation, source code you quoted, vendor examples.\n- **Medium** \u2014 reputable secondary sources, single community issue thread.\n- **Low** \u2014 blog posts, your own inference, version-uncertain info.\nAnything tagged Low/Medium that could change the design will be re-checked\nby the team \u2014 flag prominently if that is the case.\n\n## Rules\n- Cite sources with paths or links.  Never fabricate URLs or API details.\n- Separate fact from interpretation explicitly.\n- Prefer official documentation; quote the relevant lines when reading code.\n- State which product/version each finding applies to.\n\n## Web lookups (two channels)\nYou are one of the two network roles (the other is the team lead).\n1. HIGH priority \u2014 TeamMode governed tools:\n   - tm_search (open-ended lookups): ONE call \u2014 pass the raw query, pick an\n     engine, get an extracted title+URL hit list (not the raw page).\n     Engines: bing (default) \u00B7 bing-int (international results) \u00B7 sogou \u00B7\n     so (360) \u00B7 baidu \u00B7 bilibili \u00B7 moegirl (wiki, structured) \u00B7 npm\n     (packages, structured) \u00B7 github (repos, structured).  On an empty\n     result switch engines \u2014 the error names the alternatives.\n   - tm_webfetch (known URL): one governed GET of an allowlisted page;\n     search-engine result pages it fetches are auto-extracted to hit lists.\n   - tm_browser (interactive): open \u2192 navigate \u2192 read (page text) \u2192\n     screenshot \u2192 close.  A visible browser window opens on desktops;\n     display-less hosts run headless automatically.  Isolated temp\n     profile; per-request domain allowlist enforced at the network layer.\n2. FALLBACK \u2014 user-configured MCP/plugin tools (browser automation, web\n   search, page fetchers) for what tm_search / tm_browser / tm_webfetch\n   cannot do.\n   Seeded allowlist hosts and shapes (extend via\n   TM_WEBFETCH_ALLOWED_DOMAINS):\n   - wiki term:  https://mobile.moegirl.org.cn/TERM\n   - bilibili:   https://search.bilibili.com/all?keyword=QUERY\n   - bing:       https://cn.bing.com/search?q=QUERY (append &ensearch=1\n                 for international results)\n   - baidu:      https://www.baidu.com/s?wd=QUERY\n   - sogou:      https://www.sogou.com/web?query=QUERY\n   - 360:        https://www.so.com/s?q=QUERY\n   - npm pkg:    https://registry.npmjs.org/<pkg>/latest\n   - npm search: https://registry.npmjs.org/-/v1/search?text=QUERY\n   - gh repos:   https://api.github.com/search/repositories?q=QUERY\n   URL-encode the query (CJK terms too).  Expand colloquial, abbreviated,\n   or aliased terms to canonical forms and fetch BOTH spellings before\n   concluding \"not found\".\nOversized pages come back as a handle \u2014 page with tm_fetch (try\nmode:\"structure\" first).  Never fabricate page content \u2014 an unfetchable\nclaim stays unfetched and is reported as a gap.\n\n## Behavioral constraints\n- When analyzing dependencies, output call-graph diagrams in mermaid format.\n- When the code under study involves authentication/authorization, tag each\n  finding with a security-risk level (Critical / High / Medium / Low).\n- When encountering unfamiliar modules, note what additional context would\n  help and suggest which tool or command could retrieve it.\n- Before starting deep analysis, check whether a design doc or prior\n  research artifact already exists in the project \u2014 reference it instead\n  of re-deriving.\n";
+//# sourceMappingURL=specialists.d.ts.map

package/dist/prompts/specialists.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"specialists.d.ts","sourceRoot":"","sources":["../../src/prompts/specialists.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH,eAAO,MAAM,gBAAgB,85CA6B5B,CAAA;AAED,eAAO,MAAM,kBAAkB,uoCAwB9B,CAAA;AAED,eAAO,MAAM,eAAe,6mEA2C3B,CAAA;AAED,eAAO,MAAM,aAAa,guFA2DzB,CAAA;AAED,eAAO,MAAM,iBAAiB,ijIA0E7B,CAAA"}

package/dist/prompts/specialists.js

@@ -0,0 +1,241 @@
+/**
+ * The five specialist system prompts (architect / implementer / reviewer /
+ * tester / researcher).  Extracted verbatim from the former monolithic
+ * agents.ts — pinned by test-blackboard.mjs; do not reword without adding
+ * a matching assertion.
+ */
+export const ARCHITECT_PROMPT = `You are the **Architect** on a multi-agent coding team.
+
+## Role
+You produce clear, implementable technical designs.  You think in systems:
+interfaces, data flow, module boundaries, trade-offs.
+
+## Output format
+For every design task, produce:
+1. **Overview** — one-paragraph summary of the design.
+2. **Components** — each module/file with its responsibility.
+3. **Interfaces** — key type definitions, function signatures, API contracts.
+4. **Data flow** — how data moves through the system (text diagrams welcome).
+5. **Task breakdown** — ordered implementation steps the implementer follows,
+   with dependencies marked.
+6. **Assumptions** — everything you assumed (behavior, inputs, environment).
+   Tag each with High / Medium / Low confidence; low ones need verification.
+7. **Risks & open questions** — what is uncertain or worth a second look.
+
+## Design revision mode
+When the team lead sends back a design flaw found in review or testing:
+- Produce a **delta** ("what changes and why"), not a full rewrite.
+- Re-check the flawed section against the actual code before proposing.
+
+## Rules
+- Prefer simplicity.  Do not over-engineer.
+- Use existing patterns and libraries found in the project.
+- Be explicit about file paths and naming conventions.
+- Ground every design in reality: read the relevant files yourself instead
+  of guessing about the codebase.
+`;
+export const IMPLEMENTER_PROMPT = `You are the **Implementer** on a multi-agent coding team.
+
+## Role
+You write clean, production-quality code following the design spec handed
+to you by the team lead.
+
+## Standard mode
+- Follow the design spec.  If it is ambiguous, pick the simpler
+  interpretation and note the assumption in your output.
+- Match the project's existing code style and conventions.
+- Handle errors properly — no silent failures.
+- Inline comments only where the *why* is non-obvious.
+- Do not write tests (that is the tester's job) unless explicitly asked.
+- Finish with a list of every file created or modified.
+
+## Fix mode (when the dispatch contains review findings or failing tests)
+- Treat each finding / failure as a numbered work item.
+- For every item, state in your output: the finding, what you changed, and
+  the file:line of the change.
+- Fix only what the items cover.  Drive-by refactors during a fix round
+  make re-review harder — if you spot an unrelated problem, list it at the
+  end instead of fixing it.
+- After changes, run the narrowest check that proves the fix (build, type
+  check, the previously failing test).
+`;
+export const REVIEWER_PROMPT = `You are the **Reviewer** on a multi-agent coding team.
+
+## Role
+You review EXACTLY ONE dimension of a change — the one named in your
+dispatch.  When parallel reviewers cover the other dimensions, ignoring
+them is your job, not laziness.  The dimensions:
+- **completeness** — requirements coverage,
+- **correctness** — logic & security,
+- **impact** — regressions & blast radius.
+If the dispatch names no dimension, review correctness and say so at the
+top of your report.
+
+## Dimension checklists
+**Completeness** — go requirement by requirement: is each one actually
+implemented?  No half-done items, no silently dropped subtasks, no
+"coming in a follow-up" without the lead's sign-off.  Compare the stated
+plan/spec against the real diff.
+**Correctness** — logic errors, edge cases, off-by-one, null safety,
+injection, auth bypass, secrets exposure, validation gaps, silent
+failure paths.
+**Impact** — what else can this break?  Downstream consumers,
+API/schema compatibility, performance characteristics, migration needs,
+config and docs that now lie.
+
+## Severity scale (drives the team's feedback loop — grade honestly)
+- 🔴 **Critical** — must fix; broken behavior or security hole.
+- 🟠 **Major** — must fix; real defect or significant risk.
+- 🟡 **Minor** — should fix, non-blocking.
+- 🔵 **Nit** — style/preference, take-it-or-leave-it.
+- ✅ **Praise** — good patterns worth keeping visible.
+
+Findings at Critical/Major automatically become fix tasks, so only assign
+them for genuine defects — inflating severity stalls the team.
+
+## Output format
+For each finding: file:line, what is wrong, why it matters, concrete fix
+(code snippet where it helps).  End with a verdict line:
+\`VERDICT: approve\` or \`VERDICT: request changes (N critical, M major)\`.
+
+## Re-review mode
+When re-reviewing after fixes, stay within your dimension: focus ONLY on
+the previously flagged scope plus regressions introduced by the fixes;
+confirm each prior finding item by item (fixed / not fixed / partial).
+`;
+export const TESTER_PROMPT = `You are the **Tester** on a multi-agent coding team.
+
+## Role
+You write comprehensive, maintainable tests and give the team a trustworthy
+pass/fail signal.
+
+## Strategy
+1. Read the implementation thoroughly before writing any test.
+2. Cover happy path, edge cases, and error paths.
+3. Use the project's existing test framework, runner, and conventions.
+4. Table-driven tests (or equivalent) for parameterized cases.
+5. Mock external dependencies; test units in isolation.
+
+## Verification stack (default, in order)
+1. Build / typecheck.
+2. Static analysis / lint.
+3. Unit and API-level tests.
+A "passed" verdict cites the actual command output for each layer that
+ran.
+
+## Prohibited improvisation
+Do NOT invent environment hacks as "verification": no ad-hoc headless
+browser invocations (e.g. \`msedge --headless\` screenshots), no HTTP
+requests against UI pages as UI proof, no hand-written DOM stubs.  If the
+project ALREADY ships a browser-test setup (e.g. a Playwright config in
+the repo), you may use that tooling as designed.
+
+## UI verification (tm_browser — you carry it)
+For user-visible frontend changes, verify through the governed tm_browser
+instead of improvising: open → navigate → read (page text) → screenshot →
+close.  It drives the user's own Chromium-family browser headful, with an
+isolated temp profile and a domain-allowlisted network layer.  Your use is
+UI verification of THIS project (local dev servers, deployed preview
+routes) — open web browsing stays with the lead and the researcher.  If
+tm_browser is unavailable on this host, or the route needs credentials you
+were not given, end your report with:
+\`UI NOT VERIFIED: <what still needs manual checking>\`
+so the lead can relay it honestly to the user.  Pretending otherwise is
+worse than admitting the gap.
+
+## Failure classification (required for every failing case)
+- **PRODUCT_BUG** — the code is wrong.  Include minimal repro + expected
+  vs actual.  The lead will route this to the implementer.
+- **TEST_DEFECT** — the test itself is wrong/flaky.  Fix it yourself.
+- **ENVIRONMENT** — tooling/deps/config issue.  Report precisely; do not
+  work around silently.
+
+## Output format
+- Test files created/modified.
+- Run command used and result: passed / failed / error counts.
+- Per-failure classification line as above.
+- Verdict line: \`VERDICT: pass\` or \`VERDICT: fail (N product bugs)\`.
+
+## Rules
+- Tests must be deterministic — no flaky tests.
+- One behavior per test; descriptive names state the expectation.
+- Boundaries always: empty input, max values, null/undefined.
+- If the code is untestable as-is, say so and propose the minimal
+  refactor instead of contorting the test.
+`;
+export const RESEARCHER_PROMPT = `You are the **Researcher** on a multi-agent coding team.
+
+## Role
+You find accurate, actionable information so the team can make informed
+decisions.  Your output feeds a verification loop — tag honestly.
+
+## Output format
+1. **Summary** — key findings in 2-3 sentences.
+2. **Findings** — one entry per fact/answer:
+   - statement
+   - \`[confidence: High|Medium|Low]\`
+   - source (official docs / source code / issue tracker / blog / inference)
+3. **Recommendation** — what the team should do, with trade-offs.
+4. **Gaps** — what you could not confirm and what would confirm it.
+
+## Confidence calibration
+- **High** — official documentation, source code you quoted, vendor examples.
+- **Medium** — reputable secondary sources, single community issue thread.
+- **Low** — blog posts, your own inference, version-uncertain info.
+Anything tagged Low/Medium that could change the design will be re-checked
+by the team — flag prominently if that is the case.
+
+## Rules
+- Cite sources with paths or links.  Never fabricate URLs or API details.
+- Separate fact from interpretation explicitly.
+- Prefer official documentation; quote the relevant lines when reading code.
+- State which product/version each finding applies to.
+
+## Web lookups (two channels)
+You are one of the two network roles (the other is the team lead).
+1. HIGH priority — TeamMode governed tools:
+   - tm_search (open-ended lookups): ONE call — pass the raw query, pick an
+     engine, get an extracted title+URL hit list (not the raw page).
+     Engines: bing (default) · bing-int (international results) · sogou ·
+     so (360) · baidu · bilibili · moegirl (wiki, structured) · npm
+     (packages, structured) · github (repos, structured).  On an empty
+     result switch engines — the error names the alternatives.
+   - tm_webfetch (known URL): one governed GET of an allowlisted page;
+     search-engine result pages it fetches are auto-extracted to hit lists.
+   - tm_browser (interactive): open → navigate → read (page text) →
+     screenshot → close.  A visible browser window opens on desktops;
+     display-less hosts run headless automatically.  Isolated temp
+     profile; per-request domain allowlist enforced at the network layer.
+2. FALLBACK — user-configured MCP/plugin tools (browser automation, web
+   search, page fetchers) for what tm_search / tm_browser / tm_webfetch
+   cannot do.
+   Seeded allowlist hosts and shapes (extend via
+   TM_WEBFETCH_ALLOWED_DOMAINS):
+   - wiki term:  https://mobile.moegirl.org.cn/TERM
+   - bilibili:   https://search.bilibili.com/all?keyword=QUERY
+   - bing:       https://cn.bing.com/search?q=QUERY (append &ensearch=1
+                 for international results)
+   - baidu:      https://www.baidu.com/s?wd=QUERY
+   - sogou:      https://www.sogou.com/web?query=QUERY
+   - 360:        https://www.so.com/s?q=QUERY
+   - npm pkg:    https://registry.npmjs.org/<pkg>/latest
+   - npm search: https://registry.npmjs.org/-/v1/search?text=QUERY
+   - gh repos:   https://api.github.com/search/repositories?q=QUERY
+   URL-encode the query (CJK terms too).  Expand colloquial, abbreviated,
+   or aliased terms to canonical forms and fetch BOTH spellings before
+   concluding "not found".
+Oversized pages come back as a handle — page with tm_fetch (try
+mode:"structure" first).  Never fabricate page content — an unfetchable
+claim stays unfetched and is reported as a gap.
+
+## Behavioral constraints
+- When analyzing dependencies, output call-graph diagrams in mermaid format.
+- When the code under study involves authentication/authorization, tag each
+  finding with a security-risk level (Critical / High / Medium / Low).
+- When encountering unfamiliar modules, note what additional context would
+  help and suggest which tool or command could retrieve it.
+- Before starting deep analysis, check whether a design doc or prior
+  research artifact already exists in the project — reference it instead
+  of re-deriving.
+`;
+//# sourceMappingURL=specialists.js.map

package/dist/prompts/specialists.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"specialists.js","sourceRoot":"","sources":["../../src/prompts/specialists.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH,MAAM,CAAC,MAAM,gBAAgB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6B/B,CAAA;AAED,MAAM,CAAC,MAAM,kBAAkB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;CAwBjC,CAAA;AAED,MAAM,CAAC,MAAM,eAAe,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA2C9B,CAAA;AAED,MAAM,CAAC,MAAM,aAAa,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA2D5B,CAAA;AAED,MAAM,CAAC,MAAM,iBAAiB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA0EhC,CAAA"}

package/dist/shell-text.d.ts

@@ -0,0 +1,14 @@
+/**
+ * Shared shell statement segmentation — the ONE implementation of "split a
+ * command into shell segments" (compound statements and pipelines are
+ * checked at every boundary).  Previously duplicated between
+ * envprotect/bash-classify.ts and tm/guard.ts; behavior identical in both.
+ */
+/**
+ * Split a command into shell segments so compound statements like
+ * `cd /x && printenv` are checked at every statement boundary.
+ * NOTE: quoted `|`/`;` are literal text — callers that must not split on
+ * them blank quoted spans FIRST (see tm/guard.ts blankQuoted).
+ */
+export declare function splitShellSegments(command: string): string[];
+//# sourceMappingURL=shell-text.d.ts.map

package/dist/shell-text.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"shell-text.d.ts","sourceRoot":"","sources":["../src/shell-text.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH;;;;;GAKG;AACH,wBAAgB,kBAAkB,CAAC,OAAO,EAAE,MAAM,GAAG,MAAM,EAAE,CAE5D"}

package/dist/shell-text.js

@@ -0,0 +1,16 @@
+/**
+ * Shared shell statement segmentation — the ONE implementation of "split a
+ * command into shell segments" (compound statements and pipelines are
+ * checked at every boundary).  Previously duplicated between
+ * envprotect/bash-classify.ts and tm/guard.ts; behavior identical in both.
+ */
+/**
+ * Split a command into shell segments so compound statements like
+ * `cd /x && printenv` are checked at every statement boundary.
+ * NOTE: quoted `|`/`;` are literal text — callers that must not split on
+ * them blank quoted spans FIRST (see tm/guard.ts blankQuoted).
+ */
+export function splitShellSegments(command) {
+    return command.split(/&&|\|\||[;\n|&]/);
+}
+//# sourceMappingURL=shell-text.js.map

package/dist/shell-text.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"shell-text.js","sourceRoot":"","sources":["../src/shell-text.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH;;;;;GAKG;AACH,MAAM,UAAU,kBAAkB,CAAC,OAAe;IAChD,OAAO,OAAO,CAAC,KAAK,CAAC,iBAAiB,CAAC,CAAA;AACzC,CAAC"}

package/dist/tm/args-schema.d.ts

@@ -0,0 +1,42 @@
+/**
+ * tm layer — zod arg schemas (ZodRawShape) with descriptor fallback.
+ * Split out of the former tools.ts hub; behavior unchanged.
+ *
+ * Per-tool `args` — a ZodRawShape (plain `{key: validator}` object, official
+ * tool.d.ts:47-50), NOT a z.object(): the host serializes the raw shape into
+ * the LLM parameter spec.  Wrapping it in z.object produced `{def:{command:
+ * ...}}` garbage args in real sessions (the model wrapped its args 3/3
+ * times), even though flat args reached execute fine.
+ */
+declare function buildArgsSchemas(): Promise<Record<string, Record<string, unknown>>>;
+export { buildArgsSchemas };
+/**
+ * tm_ptc_run args — same ZodRawShape treatment (BUG#3 class): a raw shape
+ * when zod is available, descriptors otherwise.  Kept separate from
+ * buildArgsSchemas because buildPtcRunTool is sync; tm/index awaits this
+ * once and passes the result in as `deps.args`.
+ */
+export declare function buildPtcArgsSchema(): Promise<Record<string, unknown>>;
+/**
+ * tm_webfetch args — same ZodRawShape treatment (BUG#3 class); descriptor
+ * fallback when zod is absent.  tm/index awaits this and passes the result
+ * into buildTmWebfetchTool as `deps.args`.
+ */
+export declare function buildWebfetchArgsSchema(): Promise<Record<string, unknown>>;
+/**
+ * tm_search args — same ZodRawShape treatment (BUG#3 class); descriptor
+ * fallback when zod is absent.  tm/index awaits this and passes the result
+ * into buildTmSearchTool as `deps.args`.
+ */
+export declare function buildSearchArgsSchema(): Promise<Record<string, unknown>>;
+/**
+ * tm_memory args — same ZodRawShape treatment (BUG#3 class); descriptor
+ * fallback when zod is absent.
+ */
+export declare function buildMemoryArgsSchema(): Promise<Record<string, unknown>>;
+/**
+ * tm_browser args — same ZodRawShape treatment (BUG#3 class); descriptor
+ * fallback when zod is absent.
+ */
+export declare function buildBrowserArgsSchema(): Promise<Record<string, unknown>>;
+//# sourceMappingURL=args-schema.d.ts.map

package/dist/tm/args-schema.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"args-schema.d.ts","sourceRoot":"","sources":["../../src/tm/args-schema.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAkCH,iBAAe,gBAAgB,IAAI,OAAO,CAAC,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC,CAAC,CA2ElF;AAED,OAAO,EAAE,gBAAgB,EAAE,CAAA;AAE3B;;;;;GAKG;AACH,wBAAsB,kBAAkB,IAAI,OAAO,CAAC,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC,CA+B3E;AAED;;;;GAIG;AACH,wBAAsB,uBAAuB,IAAI,OAAO,CAAC,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC,CAiBhF;AAED;;;;GAIG;AACH,wBAAsB,qBAAqB,IAAI,OAAO,CAAC,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC,CAoB9E;AAED;;;GAGG;AACH,wBAAsB,qBAAqB,IAAI,OAAO,CAAC,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC,CA2B9E;AAED;;;GAGG;AACH,wBAAsB,sBAAsB,IAAI,OAAO,CAAC,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC,CAkB/E"}

package/dist/tm/args-schema.js

@@ -0,0 +1,213 @@
+/**
+ * tm layer — zod arg schemas (ZodRawShape) with descriptor fallback.
+ * Split out of the former tools.ts hub; behavior unchanged.
+ *
+ * Per-tool `args` — a ZodRawShape (plain `{key: validator}` object, official
+ * tool.d.ts:47-50), NOT a z.object(): the host serializes the raw shape into
+ * the LLM parameter spec.  Wrapping it in z.object produced `{def:{command:
+ * ...}}` garbage args in real sessions (the model wrapped its args 3/3
+ * times), even though flat args reached execute fine.
+ */
+/**
+ * Load zod when the host environment provides it (opencode ships it as a
+ * peer); fall back to plain arg descriptors so the plugin never hard-depends
+ * on it.  execute() is defensive either way — it coerces raw args itself.
+ */
+async function loadZod() {
+    try {
+        const spec = "zod";
+        const mod = await import(spec);
+        const z = mod?.z ??
+            mod?.default?.z ??
+            null;
+        return z && typeof z.object === "function"
+            ? z
+            : null;
+    }
+    catch {
+        return null;
+    }
+}
+function describe(z, schema, fallback) {
+    if (z && typeof z.string === "function") {
+        return schema;
+    }
+    return { descriptor: fallback };
+}
+async function buildArgsSchemas() {
+    const z = await loadZod();
+    if (!z) {
+        return {
+            tm_read: describe(null, null, "path: string (required)"),
+            tm_grep: describe(null, null, "pattern: string (required), path: string (optional)"),
+            tm_bash: describe(null, null, "command: string (required, read-only allowlisted)"),
+            tm_fetch: describe(null, null, "ref: string (required), access_token: string, offset: int, limit: int, mode: lines|structure"),
+        };
+    }
+    const zz = z;
+    // RAW SHAPES — no zz.object() wrapper (BUG#3).
+    return {
+        tm_read: {
+            path: zz
+                .string()
+                .describe("File path, relative to the project root (or absolute within it). Env files (.env, *.env, .bashrc family) are rejected — same R6 source as the built-in read."),
+        },
+        tm_grep: {
+            pattern: zz.string().describe("Regex to search (ripgrep syntax)."),
+            path: zz
+                .string()
+                .describe("Optional directory scope, relative to the project root.")
+                .optional(),
+        },
+        tm_bash: {
+            command: zz
+                .string()
+                .describe("Read-only shell command (allowlisted heads only). bash on POSIX, PowerShell-like on Windows."),
+        },
+        tm_fetch: {
+            ref: zz
+                .string()
+                .describe("Offload handle ref: tm://runs/{run_id}/steps/{step_id}/result"),
+            access_token: zz
+                .string()
+                .describe("HMAC token from the offload handle (may also ride the ref fragment).")
+                .optional(),
+            offset: zz
+                .number()
+                .int()
+                .min(0)
+                .describe("0-based line offset of the first line to return.")
+                .optional(),
+            limit: zz
+                .number()
+                .int()
+                .min(1)
+                .describe("Max lines per fetch, capped at TM_FETCH_MAX_LINES (default 2000).")
+                .optional(),
+            mode: zz
+                .enum(["lines", "structure"])
+                .describe("structure = ~100-token TOC / key tree / error-line map; try it first.")
+                .optional(),
+        },
+    };
+}
+export { buildArgsSchemas };
+/**
+ * tm_ptc_run args — same ZodRawShape treatment (BUG#3 class): a raw shape
+ * when zod is available, descriptors otherwise.  Kept separate from
+ * buildArgsSchemas because buildPtcRunTool is sync; tm/index awaits this
+ * once and passes the result in as `deps.args`.
+ */
+export async function buildPtcArgsSchema() {
+    const z = await loadZod();
+    if (!z) {
+        return {
+            program: { descriptor: "program: string (required, async fn body, ≤TM_PTC_MAX_PROGRAM_CHARS)" },
+            label: { descriptor: "label: string (optional, ≤80 chars)" },
+            budgets: { descriptor: "budgets: { max_calls?, max_errors?, timeout_ms? } (optional, tighten-only)" },
+        };
+    }
+    const zz = z;
+    return {
+        program: zz
+            .string()
+            .describe("Async function body. Available: tm.read(args), tm.grep(args), tm.bash(args), tm.fetch(args) — each returns {ok:true, data} or {ok:false, error:{tool,phase,line?,message}}. `return` a value for the aggregation summary."),
+        label: zz.string().describe("Optional run label (≤80 chars).").optional(),
+        budgets: zz
+            .any()
+            .describe("Optional budgets object { max_calls?, max_errors?, timeout_ms? } — tighten-only, clamped to the TM_PTC_* ceilings.")
+            .optional(),
+    };
+}
+/**
+ * tm_webfetch args — same ZodRawShape treatment (BUG#3 class); descriptor
+ * fallback when zod is absent.  tm/index awaits this and passes the result
+ * into buildTmWebfetchTool as `deps.args`.
+ */
+export async function buildWebfetchArgsSchema() {
+    const z = await loadZod();
+    if (!z) {
+        return {
+            url: { descriptor: "url: string (required, absolute https URL on an allowlisted host, query URL-encoded)" },
+        };
+    }
+    const zz = z;
+    return {
+        url: zz
+            .string()
+            .describe("Absolute https URL on an allowlisted host (seeded: mobile.moegirl.org.cn, search.bilibili.com, cn.bing.com, www.baidu.com, www.sogou.com, www.so.com, registry.npmjs.org, api.github.com). URL-encode the query (CJK terms too)."),
+    };
+}
+/**
+ * tm_search args — same ZodRawShape treatment (BUG#3 class); descriptor
+ * fallback when zod is absent.  tm/index awaits this and passes the result
+ * into buildTmSearchTool as `deps.args`.
+ */
+export async function buildSearchArgsSchema() {
+    const z = await loadZod();
+    if (!z) {
+        return {
+            query: { descriptor: "query: string (required, raw text — CJK fine, encoded here)" },
+            engine: { descriptor: "engine: bing|bing-int|sogou|so|baidu|bilibili|npm|github (optional, default bing)" },
+        };
+    }
+    const zz = z;
+    return {
+        query: zz.string().describe("Raw search query — pass text as-is; the tool URL-encodes it (CJK included)."),
+        engine: zz
+            .string()
+            .describe("bing (default) | bing-int (international results) | sogou | so (360) | baidu | bilibili | moegirl (wiki search API, structured) | npm (registry search, structured) | github (repo search API, structured).")
+            .optional(),
+    };
+}
+/**
+ * tm_memory args — same ZodRawShape treatment (BUG#3 class); descriptor
+ * fallback when zod is absent.
+ */
+export async function buildMemoryArgsSchema() {
+    const z = await loadZod();
+    if (!z) {
+        return {
+            action: { descriptor: "action: add|search|list|forget (required)" },
+            title: { descriptor: "title: string (add/forget)" },
+            content: { descriptor: "content: string (add, ≤4000 chars)" },
+            category: { descriptor: "category: string (add, optional)" },
+            keywords: { descriptor: "keywords: string[] or comma string (add, optional)" },
+            usage_scenario: { descriptor: "usage_scenario: string[] or comma string (add, optional)" },
+            query: { descriptor: "query: string (search)" },
+            scope: { descriptor: "scope: project|global (optional, default project)" },
+        };
+    }
+    const zz = z;
+    return {
+        action: zz.string().describe("add | search | list | forget."),
+        title: zz.string().describe("Memory title (add/forget).").optional(),
+        content: zz.string().describe("One condensed fact, ≤4000 chars (add).").optional(),
+        category: zz.string().describe("Category slug, e.g. project_tech_stack (add, optional).").optional(),
+        keywords: zz.string().describe("Comma-separated keywords (add, optional).").optional(),
+        usage_scenario: zz.string().describe("Comma-separated when-to-use scenarios (add, optional).").optional(),
+        query: zz.string().describe("Search query (search).").optional(),
+        scope: zz.string().describe("project (default) | global.").optional(),
+    };
+}
+/**
+ * tm_browser args — same ZodRawShape treatment (BUG#3 class); descriptor
+ * fallback when zod is absent.
+ */
+export async function buildBrowserArgsSchema() {
+    const z = await loadZod();
+    if (!z) {
+        return {
+            action: { descriptor: 'action: open|navigate|read|screenshot|close (required)' },
+            url: { descriptor: 'url: string (open/navigate, allowlisted https)' },
+            headless: { descriptor: 'headless: boolean (open, optional — default auto)' },
+        };
+    }
+    const zz = z;
+    return {
+        action: zz.string().describe('open | navigate | read | screenshot | close.'),
+        url: zz.string().describe('Absolute https URL on an allowlisted host (open/navigate). URL-encode the query (CJK terms too).').optional(),
+        headless: zz.boolean().describe('Force headless/headful on open (optional — default auto by display availability).').optional(),
+    };
+}
+//# sourceMappingURL=args-schema.js.map

package/dist/tm/args-schema.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"args-schema.js","sourceRoot":"","sources":["../../src/tm/args-schema.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH;;;;GAIG;AACH,KAAK,UAAU,OAAO;IACpB,IAAI,CAAC;QACH,MAAM,IAAI,GAAG,KAAK,CAAA;QAClB,MAAM,GAAG,GAAY,MAAM,MAAM,CAAC,IAAI,CAAC,CAAA;QACvC,MAAM,CAAC,GACJ,GAAuB,EAAE,CAAC;YAC1B,GAAqC,EAAE,OAAO,EAAE,CAAC;YAClD,IAAI,CAAA;QACN,OAAO,CAAC,IAAI,OAAQ,CAA0B,CAAC,MAAM,KAAK,UAAU;YAClE,CAAC,CAAE,CAA6B;YAChC,CAAC,CAAC,IAAI,CAAA;IACV,CAAC;IAAC,MAAM,CAAC;QACP,OAAO,IAAI,CAAA;IACb,CAAC;AACH,CAAC;AAED,SAAS,QAAQ,CACf,CAAiC,EACjC,MAAe,EACf,QAAgB;IAEhB,IAAI,CAAC,IAAI,OAAQ,CAA0B,CAAC,MAAM,KAAK,UAAU,EAAE,CAAC;QAClE,OAAO,MAAiC,CAAA;IAC1C,CAAC;IACD,OAAO,EAAE,UAAU,EAAE,QAAQ,EAAE,CAAA;AACjC,CAAC;AAED,KAAK,UAAU,gBAAgB;IAC7B,MAAM,CAAC,GAAG,MAAM,OAAO,EAAE,CAAA;IACzB,IAAI,CAAC,CAAC,EAAE,CAAC;QACP,OAAO;YACL,OAAO,EAAE,QAAQ,CAAC,IAAI,EAAE,IAAI,EAAE,yBAAyB,CAAC;YACxD,OAAO,EAAE,QAAQ,CAAC,IAAI,EAAE,IAAI,EAAE,qDAAqD,CAAC;YACpF,OAAO,EAAE,QAAQ,CAAC,IAAI,EAAE,IAAI,EAAE,mDAAmD,CAAC;YAClF,QAAQ,EAAE,QAAQ,CAAC,IAAI,EAAE,IAAI,EAAE,8FAA8F,CAAC;SAC/H,CAAA;IACH,CAAC;IAWD,MAAM,EAAE,GAAG,CAKV,CAAA;IACD,+CAA+C;IAC/C,OAAO;QACL,OAAO,EAAE;YACP,IAAI,EAAE,EAAE;iBACL,MAAM,EAAE;iBACR,QAAQ,CACP,8JAA8J,CAC/J;SACJ;QACD,OAAO,EAAE;YACP,OAAO,EAAE,EAAE,CAAC,MAAM,EAAE,CAAC,QAAQ,CAAC,mCAAmC,CAAC;YAClE,IAAI,EAAE,EAAE;iBACL,MAAM,EAAE;iBACR,QAAQ,CAAC,yDAAyD,CAAC;iBACnE,QAAQ,EAAE;SACd;QACD,OAAO,EAAE;YACP,OAAO,EAAE,EAAE;iBACR,MAAM,EAAE;iBACR,QAAQ,CACP,8FAA8F,CAC/F;SACJ;QACD,QAAQ,EAAE;YACR,GAAG,EAAE,EAAE;iBACJ,MAAM,EAAE;iBACR,QAAQ,CAAC,+DAA+D,CAAC;YAC5E,YAAY,EAAE,EAAE;iBACb,MAAM,EAAE;iBACR,QAAQ,CAAC,sEAAsE,CAAC;iBAChF,QAAQ,EAAE;YACb,MAAM,EAAE,EAAE;iBACP,MAAM,EAAE;iBACR,GAAG,EAAE;iBACL,GAAG,CAAC,CAAC,CAAC;iBACN,QAAQ,CAAC,kDAAkD,CAAC;iBAC5D,QAAQ,EAAE;YACb,KAAK,EAAE,EAAE;iBACN,MAAM,EAAE;iBACR,GAAG,EAAE;iBACL,GAAG,CAAC,CAAC,CAAC;iBACN,QAAQ,CAAC,mEAAmE,CAAC;iBAC7E,QAAQ,EAAE;YACb,IAAI,EAAE,EAAE;iBACL,IAAI,CAAC,CAAC,OAAO,EAAE,WAAW,CAAC,CAAC;iBAC5B,QAAQ,CAAC,uEAAuE,CAAC;iBACjF,QAAQ,EAAE;SACd;KACF,CAAA;AACH,CAAC;AAED,OAAO,EAAE,gBAAgB,EAAE,CAAA;AAE3B;;;;;GAKG;AACH,MAAM,CAAC,KAAK,UAAU,kBAAkB;IACtC,MAAM,CAAC,GAAG,MAAM,OAAO,EAAE,CAAA;IACzB,IAAI,CAAC,CAAC,EAAE,CAAC;QACP,OAAO;YACL,OAAO,EAAE,EAAE,UAAU,EAAE,sEAAsE,EAAE;YAC/F,KAAK,EAAE,EAAE,UAAU,EAAE,qCAAqC,EAAE;YAC5D,OAAO,EAAE,EAAE,UAAU,EAAE,4EAA4E,EAAE;SACtG,CAAA;IACH,CAAC;IACD,MAAM,EAAE,GAAG,CAOV,CAAA;IACD,OAAO;QACL,OAAO,EAAE,EAAE;aACR,MAAM,EAAE;aACR,QAAQ,CACP,2NAA2N,CAC5N;QACH,KAAK,EAAE,EAAE,CAAC,MAAM,EAAE,CAAC,QAAQ,CAAC,iCAAiC,CAAC,CAAC,QAAQ,EAAE;QACzE,OAAO,EAAE,EAAE;aACR,GAAG,EAAE;aACL,QAAQ,CACP,oHAAoH,CACrH;aACA,QAAQ,EAAE;KACd,CAAA;AACH,CAAC;AAED;;;;GAIG;AACH,MAAM,CAAC,KAAK,UAAU,uBAAuB;IAC3C,MAAM,CAAC,GAAG,MAAM,OAAO,EAAE,CAAA;IACzB,IAAI,CAAC,CAAC,EAAE,CAAC;QACP,OAAO;YACL,GAAG,EAAE,EAAE,UAAU,EAAE,sFAAsF,EAAE;SAC5G,CAAA;IACH,CAAC;IACD,MAAM,EAAE,GAAG,CAEV,CAAA;IACD,OAAO;QACL,GAAG,EAAE,EAAE;aACJ,MAAM,EAAE;aACR,QAAQ,CACP,kOAAkO,CACnO;KACJ,CAAA;AACH,CAAC;AAED;;;;GAIG;AACH,MAAM,CAAC,KAAK,UAAU,qBAAqB;IACzC,MAAM,CAAC,GAAG,MAAM,OAAO,EAAE,CAAA;IACzB,IAAI,CAAC,CAAC,EAAE,CAAC;QACP,OAAO;YACL,KAAK,EAAE,EAAE,UAAU,EAAE,6DAA6D,EAAE;YACpF,MAAM,EAAE,EAAE,UAAU,EAAE,mFAAmF,EAAE;SAC5G,CAAA;IACH,CAAC;IACD,MAAM,EAAE,GAAG,CAEV,CAAA;IACD,OAAO;QACL,KAAK,EAAE,EAAE,CAAC,MAAM,EAAE,CAAC,QAAQ,CAAC,6EAA6E,CAAC;QAC1G,MAAM,EAAE,EAAE;aACP,MAAM,EAAE;aACR,QAAQ,CACP,6MAA6M,CAC9M;aACA,QAAQ,EAAE;KACd,CAAA;AACH,CAAC;AAED;;;GAGG;AACH,MAAM,CAAC,KAAK,UAAU,qBAAqB;IACzC,MAAM,CAAC,GAAG,MAAM,OAAO,EAAE,CAAA;IACzB,IAAI,CAAC,CAAC,EAAE,CAAC;QACP,OAAO;YACL,MAAM,EAAE,EAAE,UAAU,EAAE,2CAA2C,EAAE;YACnE,KAAK,EAAE,EAAE,UAAU,EAAE,4BAA4B,EAAE;YACnD,OAAO,EAAE,EAAE,UAAU,EAAE,oCAAoC,EAAE;YAC7D,QAAQ,EAAE,EAAE,UAAU,EAAE,kCAAkC,EAAE;YAC5D,QAAQ,EAAE,EAAE,UAAU,EAAE,oDAAoD,EAAE;YAC9E,cAAc,EAAE,EAAE,UAAU,EAAE,0DAA0D,EAAE;YAC1F,KAAK,EAAE,EAAE,UAAU,EAAE,wBAAwB,EAAE;YAC/C,KAAK,EAAE,EAAE,UAAU,EAAE,mDAAmD,EAAE;SAC3E,CAAA;IACH,CAAC;IACD,MAAM,EAAE,GAAG,CAEV,CAAA;IACD,OAAO;QACL,MAAM,EAAE,EAAE,CAAC,MAAM,EAAE,CAAC,QAAQ,CAAC,+BAA+B,CAAC;QAC7D,KAAK,EAAE,EAAE,CAAC,MAAM,EAAE,CAAC,QAAQ,CAAC,4BAA4B,CAAC,CAAC,QAAQ,EAAE;QACpE,OAAO,EAAE,EAAE,CAAC,MAAM,EAAE,CAAC,QAAQ,CAAC,wCAAwC,CAAC,CAAC,QAAQ,EAAE;QAClF,QAAQ,EAAE,EAAE,CAAC,MAAM,EAAE,CAAC,QAAQ,CAAC,yDAAyD,CAAC,CAAC,QAAQ,EAAE;QACpG,QAAQ,EAAE,EAAE,CAAC,MAAM,EAAE,CAAC,QAAQ,CAAC,2CAA2C,CAAC,CAAC,QAAQ,EAAE;QACtF,cAAc,EAAE,EAAE,CAAC,MAAM,EAAE,CAAC,QAAQ,CAAC,wDAAwD,CAAC,CAAC,QAAQ,EAAE;QACzG,KAAK,EAAE,EAAE,CAAC,MAAM,EAAE,CAAC,QAAQ,CAAC,wBAAwB,CAAC,CAAC,QAAQ,EAAE;QAChE,KAAK,EAAE,EAAE,CAAC,MAAM,EAAE,CAAC,QAAQ,CAAC,6BAA6B,CAAC,CAAC,QAAQ,EAAE;KACtE,CAAA;AACH,CAAC;AAED;;;GAGG;AACH,MAAM,CAAC,KAAK,UAAU,sBAAsB;IAC1C,MAAM,CAAC,GAAG,MAAM,OAAO,EAAE,CAAA;IACzB,IAAI,CAAC,CAAC,EAAE,CAAC;QACP,OAAO;YACL,MAAM,EAAE,EAAE,UAAU,EAAE,wDAAwD,EAAE;YAChF,GAAG,EAAE,EAAE,UAAU,EAAE,gDAAgD,EAAE;YACrE,QAAQ,EAAE,EAAE,UAAU,EAAE,mDAAmD,EAAE;SAC9E,CAAA;IACH,CAAC;IACD,MAAM,EAAE,GAAG,CAGV,CAAA;IACD,OAAO;QACL,MAAM,EAAE,EAAE,CAAC,MAAM,EAAE,CAAC,QAAQ,CAAC,8CAA8C,CAAC;QAC5E,GAAG,EAAE,EAAE,CAAC,MAAM,EAAE,CAAC,QAAQ,CAAC,kGAAkG,CAAC,CAAC,QAAQ,EAAE;QACxI,QAAQ,EAAE,EAAE,CAAC,OAAO,EAAE,CAAC,QAAQ,CAAC,mFAAmF,CAAC,CAAC,QAAQ,EAAE;KAChI,CAAA;AACH,CAAC"}

package/dist/tm/browser.d.ts

@@ -0,0 +1,52 @@
+/**
+ * tm_browser — governed interactive browser (Plan C: the user's own
+ * Chromium-family browser driven headful over the CDP pipe protocol).
+ *
+ * Feasibility proven by smoke (Edge + --remote-debugging-pipe + JSON/NUL
+ * framing over fds 3/4 — zero deps, no WebSocket implementation).  Qoder's
+ * hardening ideas are ported where the plugin can reach them:
+ *   - isolated temp user-data-dir (never the user's real profile);
+ *   - per-navigation allowlist enforced at the NETWORK layer via CDP
+ *     Fetch.requestPaused (non-allowlisted hosts get BlockedByClient —
+ *     the per-hop re-check analog);
+ *   - hardened webPreferences are the spawn's own flags (no-first-run,
+ *     no-extensions, mute);
+ *   - hard per-command timeout + explicit close; dispose kills the child.
+ *
+ * Environment adaptivity (different OpenCode hosts):
+ *   - headful by default (Plan C); display-less Linux (no DISPLAY/
+ *     WAYLAND_DISPLAY) automatically falls back to headless; TM_BROWSER_
+ *     HEADLESS=1|0 forces either way;
+ *   - browser discovery: TM_BROWSER_PATH override, then per-OS candidate
+ *     paths (Edge first on Windows — it is always there; Chrome/Chromium
+ *     elsewhere).  No browser → structured error, the agent falls back to
+ *     tm_webfetch / user MCP tools per the priority ladder.
+ *
+ * Role access mirrors tm_webfetch: network roles (team + researcher) only.
+ */
+import type { ToolResult } from "../types.js";
+import type { TmConfig } from "./config.js";
+import type { TmPipelines } from "./pipelines.js";
+/** Resolve the browser executable: TM_BROWSER_PATH override, then per-OS
+ *  candidates.  %LOCALAPPDATA% style vars are expanded on win32. */
+export declare function findBrowserExecutable(env?: Record<string, string | undefined>): string | null;
+/**
+ * Headless resolution (Plan C = headful by default):
+ *   TM_BROWSER_HEADLESS=1|true|force  → headless (servers/CI)
+ *   TM_BROWSER_HEADLESS=0|false|never → headful
+ *   auto (default)                    → headless ONLY when there is no
+ *   display possible (Linux without DISPLAY/WAYLAND_DISPLAY).
+ */
+export declare function resolveHeadless(env?: Record<string, string | undefined>): boolean;
+export declare function buildTmBrowserTool(deps: {
+    pipelines: TmPipelines;
+    cfg: TmConfig;
+    env?: Record<string, string | undefined>;
+    args?: Record<string, unknown>;
+}): {
+    description: string;
+    args: Record<string, unknown>;
+    execute: (rawArgs: Record<string, unknown>, ctx: unknown) => Promise<ToolResult>;
+    dispose: () => void;
+};
+//# sourceMappingURL=browser.d.ts.map

package/dist/tm/browser.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"browser.d.ts","sourceRoot":"","sources":["../../src/tm/browser.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AAOH,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,aAAa,CAAA;AAE7C,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,aAAa,CAAA;AAC3C,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,gBAAgB,CAAA;AA0BjD;oEACoE;AACpE,wBAAgB,qBAAqB,CAAC,GAAG,GAAE,MAAM,CAAC,MAAM,EAAE,MAAM,GAAG,SAAS,CAAe,GAAG,MAAM,GAAG,IAAI,CAgB1G;AAED;;;;;;GAMG;AACH,wBAAgB,eAAe,CAAC,GAAG,GAAE,MAAM,CAAC,MAAM,EAAE,MAAM,GAAG,SAAS,CAAe,GAAG,OAAO,CAM9F;AA0FD,wBAAgB,kBAAkB,CAAC,IAAI,EAAE;IACvC,SAAS,EAAE,WAAW,CAAA;IACtB,GAAG,EAAE,QAAQ,CAAA;IACb,GAAG,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,GAAG,SAAS,CAAC,CAAA;IACxC,IAAI,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAA;CAC/B,GAAG;IACF,WAAW,EAAE,MAAM,CAAA;IACnB,IAAI,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAA;IAC7B,OAAO,EAAE,CAAC,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAAE,GAAG,EAAE,OAAO,KAAK,OAAO,CAAC,UAAU,CAAC,CAAA;IAChF,OAAO,EAAE,MAAM,IAAI,CAAA;CACpB,CA2MA"}