@leg3ndy/otto-bridge 0.9.2 → 1.0.0

package/README.md

@@ -15,7 +15,7 @@ Para o estado atual da arquitetura, capacidades entregues, limitacoes e roadmap
 
 Para o corte de arquitetura do `0.9.0`, veja [`leg3ndy-ai-backend/docs/OTTO_BRIDGE_0_9_0_RELEASE.md`](../leg3ndy-ai-backend/docs/OTTO_BRIDGE_0_9_0_RELEASE.md).
 
-Para o patch atual `0.9.2`, com confirmacao bloqueante correta e exclusao segura via Lixeira, veja [`leg3ndy-ai-backend/docs/OTTO_BRIDGE_0_9_2_PATCH.md`](../leg3ndy-ai-backend/docs/OTTO_BRIDGE_0_9_2_PATCH.md).
+Para a release atual `1.0.0`, com runtime agentico formal e CLI interativo do bridge, veja [`leg3ndy-ai-backend/docs/OTTO_BRIDGE_1_0_0_RELEASE.md`](../leg3ndy-ai-backend/docs/OTTO_BRIDGE_1_0_0_RELEASE.md).
 
 ## Distribuicao
 
@@ -29,6 +29,7 @@ O pacote ja esta estruturado para install via CLI:
 
 ```bash
 npm install -g @leg3ndy/otto-bridge
+otto-bridge
 otto-bridge status
 otto-bridge version
 ```
@@ -37,14 +38,14 @@ Enquanto o pacote nao estiver publicado, voce pode gerar um tarball local:
 
 ```bash
 npm pack
-npm install -g ./leg3ndy-otto-bridge-0.9.2.tgz
+npm install -g ./leg3ndy-otto-bridge-1.0.0.tgz
 ```
 
-Na linha `0.9.2`, `playwright` segue como dependencia obrigatoria no `otto-bridge`. O primeiro `npm install -g @leg3ndy/otto-bridge` pode demorar mais porque instala o browser persistente usado pelo WhatsApp Web e pelos fluxos web em background do bridge.
+Na linha `1.0.0`, `playwright` segue como dependencia obrigatoria no `otto-bridge`. O primeiro `npm install -g @leg3ndy/otto-bridge` pode demorar mais porque instala o browser persistente usado pelo WhatsApp Web e pelos fluxos web em background do bridge.
 
-No macOS, a linha `0.9.2` usa o provider `macos-helper`, um helper `WKWebView` sem Dock para o WhatsApp Web. O helper sobe com user-agent de Chrome moderno para evitar o bloqueio do WhatsApp ao detectar Safari/WebKit. O runtime antigo com Chromium/Playwright fica disponivel apenas como override explicito via `OTTO_BRIDGE_WHATSAPP_RUNTIME_PROVIDER=embedded-playwright`.
+No macOS, a linha `1.0.0` usa o provider `macos-helper`, um helper `WKWebView` sem Dock para o WhatsApp Web. O helper sobe com user-agent de Chrome moderno para evitar o bloqueio do WhatsApp ao detectar Safari/WebKit. O runtime antigo com Chromium/Playwright fica disponivel apenas como override explicito via `OTTO_BRIDGE_WHATSAPP_RUNTIME_PROVIDER=embedded-playwright`.
 
-No nivel arquitetural, o `0.9.0` marcou a mudanca de papel do bridge: ele publica tools e resultados estruturados para o Otto, em vez de injetar resposta pronta como caminho principal do chat. O `0.9.2` consolida esse caminho com confirmacao bloqueante correta, exclusao segura via Lixeira, planner LLM-first e leitura/listagem local sem truncamento silencioso.
+No nivel arquitetural, o `0.9.0` marcou a mudanca de papel do bridge: ele publica tools e resultados estruturados para o Otto, em vez de injetar resposta pronta como caminho principal do chat. O `1.0.0` oficializa isso como runtime agentico e adiciona uma interface terminal propria do bridge para setup e interacao local com o Otto.
 
 ## Publicacao
 
@@ -75,6 +76,23 @@ otto-bridge help
 otto-bridge --help
 ```
 
+### Abrir o hub interativo
+
+```bash
+otto-bridge
+otto-bridge home
+```
+
+Em TTY, o comando sem argumentos agora abre o hub interativo com banner, setup, status, extensoes e o `Otto Console`.
+
+### Setup interativo
+
+```bash
+otto-bridge setup
+```
+
+Esse fluxo pede `API base URL`, `pairing code`, nome do dispositivo e executor. Em install global interativo, o pacote tambem tenta abrir esse setup automaticamente quando ainda nao existe pairing salvo.
+
 ### Parear o dispositivo
 
 ```bash
@@ -112,9 +130,17 @@ O adapter `clawd-cursor` continua disponivel como override opcional:
 otto-bridge run --executor clawd-cursor --clawd-url http://127.0.0.1:3847
 ```
 
+### Falar com o Otto no terminal
+
+```bash
+otto-bridge console
+```
+
+O console sobe o runtime local em background no mesmo processo, envia prompts naturais ao backend usando `device_token`, acompanha `device_job` por polling e resolve `confirm_required` diretamente no terminal.
+
 ### WhatsApp Web em background
 
-Fluxo recomendado na linha `0.9.2`:
+Fluxo recomendado na linha `1.0.0`:
 
 ```bash
 otto-bridge extensions --install whatsappweb
@@ -124,13 +150,13 @@ otto-bridge extensions --status whatsappweb
 
 O setup agora abre o login do WhatsApp Web no helper/background browser do proprio bridge. Depois do QR code, o Otto usa a sessao local em background, sem depender de aba visivel no Safari.
 
-Contrato da linha `0.9.2`:
+Contrato da linha `1.0.0`:
 
 - `otto-bridge extensions --setup whatsappweb`: autentica a sessao uma vez
 - `otto-bridge run`: mantem o browser persistente do WhatsApp vivo em background enquanto o runtime estiver ativo, sem depender de uma aba aberta no Safari
 - ao parar o `otto-bridge run`: o browser em background e desligado, mas a sessao local fica lembrada para o proximo boot
 
-## Handoff rapido da linha 0.9.2
+## Handoff rapido da linha 1.0.0
 
 Ja fechado no codigo:
 
@@ -139,11 +165,44 @@ Ja fechado no codigo:
 - resultado final dos `device_job` agora e persistido como contexto mais forte para o proximo turno do Otto
 - prompt bridge-aware no chat normal para ajudar o Otto a responder com base no que realmente aconteceu no device
 - runtime local agora publica `local_tools` para o Otto/backend saberem exatamente o que o device consegue fazer
+- o runtime agentico agora executa `execution_graph` granular por acao, em vez de colapsar a corrida local inteira num unico `tool_call`
+- o protocolo do runtime agora publica `graph_id`/`step_id` nos eventos de job e aceita controles por step para confirmacao/cancelamento
+- o executor `native-macos` agora reporta o step atual por acao e publica inline artifacts estruturados para resultados locais nao-uploadados
+- o `runtime_contract` agora pode declarar `workspace_context` com roots/targets e descriptors de `instruction_bundle`, `repo_manifest`, `workspace_index`, `workspace_memory` e `workspace_policy` para jobs de arquivo e shell
+- o bridge agora resolve `workspace_context` em paths absolutos, detecta `repo_root`, carrega `AGENTS.md` por precedencia e publica `instruction_bundle`, `repo_manifest`, `workspace_index`, `workspace_memory` e `workspace_policy` no resultado
+- filesystem e shell locais agora respeitam os roots declarados do workspace, em vez de operar como superficie global quando o job vier escopado
+- `workspace_policy` agora aplica perfis `observe_only`, `dev_assist`, `workspace_coding` e `release_operator` antes da execucao local de actions escopadas
+- `write_json_file`, `mkdir`, `move_file` e `delete_file` agora fazem parte da familia inicial de file ops tipadas do workspace
+- `workspace.patch`, `git.clone`, `git.fetch`, `git.checkout`, `git.rebase`, `git.merge`, `git.tag`, `git.status`, `git.diff`, `git.stage`, `git.commit`, `git.push` e `workspace.tests` agora fazem parte da primeira familia tipada de coding agent do catalogo local
+- `apply_patch`, `git_status`, `git_diff`, `run_tests`, `git_clone`, `git_fetch`, `git_checkout`, `git_rebase`, `git_merge`, `git_tag`, `git_add`, `git_commit` e `git_push` agora executam dentro do workspace escopado e devolvem snapshots estruturados em vez de shell cru
+- `apply_patch` entende o formato `*** Begin Patch ... *** End Patch`, devolve `patch_set` estruturado e continua bloqueando paths fora do workspace permitido
+- `run_tests` agora aceita `command` explicito ou `profile` tipado (`pytest`, `npm_test`, `pnpm_test`, `yarn_test`, `bun_test`, `lint`, `build`) e devolve `resolved_command` no snapshot final
+- `git_clone`, `git_fetch`, `git_checkout`, `git_rebase`, `git_merge`, `git_tag`, `git_add`, `git_commit` e `git_push` sobem com `requires_confirmation`, devolvem receipts estruturados (`git_clone_receipt`, `git_fetch_receipt`, `git_checkout_receipt`, `git_rebase_receipt`, `git_merge_receipt`, `git_tag_receipt`, `git_stage_receipt`, `git_commit_receipt`, `git_push_receipt`) e tratam `nothing_to_commit` / `Everything up-to-date` como resultado observavel do job
+- `repo_manifest` e `workspace_index` agora saem com `scoped_root_path`, manifests/lockfiles, key files e extensoes dominantes para grounding leve de repo
+- `workspace_memory` agora reaproveita o historico recente do mesmo `workspace_id` e volta atualizada no resultado do job para grounding curto entre execucoes
+- `workspace_memory` agora tambem respeita governanca persistida no backend, com `retention_days`, `retention_job_limit`, `last_cleared_at` e `last_cleared_reason`, que o modal do Otto Bridge pode ajustar sem sair do runtime
+- automacoes locais do canal `bridge` agora disparam `/v1/devices/automations/local/bridge/trigger` em cada tick, reaproveitando o mesmo runtime agentico do chat com `device_job`, approvals e replay auditaveis
+- o `runtime_contract` agora tambem pode declarar `worker_profiles`, e o executor ecoa esse bundle em `worker_profiles`/artifact para deixar explicito quais perfis de leitura, mudanca, validacao e release foram ativados no job
+- o `execution_graph` agora pode marcar `worker_id` por step, e o `runtime_contract` tambem pode declarar `worker_execution` com `budget_seconds`, `timeout_seconds`, `retry_limit` e `max_parallel_tasks` por worker para preparar fan-out controlado
+- o backend agora deriva `runtime_workers` e `runtime_handoffs` persistidos do mesmo graph, incluindo `worker_run_id`, `fanout_level/wave/group` e retry por worker a partir de `retry_of_worker_run_id` / `retry_attempt`
+- `git_diff` agora carrega `stat` e `diff_excerpt`, e o backend usa isso para grounding mais estrito de respostas sobre diff longo
+- o `runtime_contract` agora tambem declara `command_packs` formais (`plan-fast`, `plan-deep`, `instruction-updater`), e o bridge ecoa esses modos como artifact estruturado para deixar claro qual intensidade de planejamento/manutencao foi aplicada no job
+- o `instruction_updater` agora e um descriptor explicito do runtime, com `source_entrypoints`, `target_paths` e `recommended_validation_stage_ids` quando o plano toca `AGENTS.md`, `README.md` ou `docs/`
+- `workspace.tests` agora consegue resolver `profile=auto` via `validation_ladder`, executando stages como `typecheck`, `build`, `node_test`, `lint` e `pytest` por stack, com snapshot agregado por etapa
+- o executor `native-macos` agora publica `runtime_hook_trace` somando hooks de lifecycle e tool-use (`session_start`, `pre_tool_use`, `post_tool_use`, `validation_ladder_started/completed`, `session_end`), preparando enforcement, replay fino e metricas futuras
+- o bridge agora possui um CLI interativo proprio com setup inicial, hub terminal e `Otto Console` para prompts locais pelo proprio terminal
+- o backend agora expoe um caminho `device-auth` para o console do bridge submeter prompt e acompanhar approval/job usando apenas `device_token`
 - o caminho principal do bridge usa `summary`/`narration_context` no lugar de resposta automatica pronta
 - `read_file` agora entrega conteudo completo segmentado em `content_chunks` para o Otto
 - `list_files` sem `limit` agora lista o diretorio inteiro, sem fallback silencioso para 40 itens
 - o planner do bridge prioriza o modelo para escolher a tool certa pelo contexto; regex fica como fallback
 
+### Testes locais do runtime
+
+```bash
+npm run test:runtime
+```
+
 Ainda precisa reteste em campo:
 
 - fluxo completo do WhatsApp no helper `macos-helper`

package/dist/agentic_runtime/patch/structured_patch.js

@@ -0,0 +1,240 @@
+function normalizePatchText(value) {
+    return value.replace(/\r\n/g, "\n");
+}
+function requirePatchPath(prefix, line) {
+    const targetPath = line.slice(prefix.length).trim();
+    if (!targetPath) {
+        throw new Error("O apply_patch recebeu uma operacao sem caminho de arquivo.");
+    }
+    return targetPath;
+}
+function parseUpdateHunks(lines) {
+    const hunks = [];
+    let current = null;
+    const ensureCurrentHunk = () => {
+        if (!current) {
+            current = { header: "@@", lines: [] };
+            hunks.push(current);
+        }
+        return current;
+    };
+    for (const line of lines) {
+        if (!line.trim()) {
+            continue;
+        }
+        if (line.startsWith("@@")) {
+            current = { header: line.trim(), lines: [] };
+            hunks.push(current);
+            continue;
+        }
+        if (line === "*** End of File") {
+            continue;
+        }
+        const prefix = line.slice(0, 1);
+        const hunk = ensureCurrentHunk();
+        if (prefix === " ") {
+            hunk.lines.push({ kind: "context", text: line.slice(1) });
+            continue;
+        }
+        if (prefix === "+") {
+            hunk.lines.push({ kind: "add", text: line.slice(1) });
+            continue;
+        }
+        if (prefix === "-") {
+            hunk.lines.push({ kind: "delete", text: line.slice(1) });
+            continue;
+        }
+        throw new Error(`Linha invalida no apply_patch: ${line}`);
+    }
+    return hunks.filter((item) => item.lines.length > 0);
+}
+export function parseStructuredPatch(patchText) {
+    const normalized = normalizePatchText(String(patchText || ""));
+    const lines = normalized.split("\n");
+    const operations = [];
+    let index = 0;
+    while (index < lines.length && !lines[index]?.trim()) {
+        index += 1;
+    }
+    if (lines[index]?.trim() !== "*** Begin Patch") {
+        throw new Error("O apply_patch exige o formato *** Begin Patch ... *** End Patch.");
+    }
+    index += 1;
+    while (index < lines.length) {
+        const line = lines[index]?.trimEnd() || "";
+        if (!line.trim()) {
+            index += 1;
+            continue;
+        }
+        if (line.trim() === "*** End Patch") {
+            return {
+                operations,
+                patch_char_count: normalized.length,
+            };
+        }
+        if (line.startsWith("*** Add File: ")) {
+            const targetPath = requirePatchPath("*** Add File: ", line);
+            index += 1;
+            const contentLines = [];
+            while (index < lines.length) {
+                const currentLine = lines[index] || "";
+                if (currentLine.startsWith("*** ")) {
+                    break;
+                }
+                if (!currentLine.startsWith("+")) {
+                    throw new Error(`Linha invalida em Add File: ${currentLine}`);
+                }
+                contentLines.push(currentLine.slice(1));
+                index += 1;
+            }
+            operations.push({
+                type: "add",
+                path: targetPath,
+                content_lines: contentLines,
+            });
+            continue;
+        }
+        if (line.startsWith("*** Delete File: ")) {
+            operations.push({
+                type: "delete",
+                path: requirePatchPath("*** Delete File: ", line),
+            });
+            index += 1;
+            continue;
+        }
+        if (line.startsWith("*** Update File: ")) {
+            const targetPath = requirePatchPath("*** Update File: ", line);
+            index += 1;
+            let moveTo;
+            if ((lines[index] || "").startsWith("*** Move to: ")) {
+                moveTo = requirePatchPath("*** Move to: ", lines[index] || "");
+                index += 1;
+            }
+            const updateLines = [];
+            while (index < lines.length) {
+                const currentLine = lines[index] || "";
+                if (currentLine.startsWith("*** Add File: ")
+                    || currentLine.startsWith("*** Delete File: ")
+                    || currentLine.startsWith("*** Update File: ")
+                    || currentLine.trim() === "*** End Patch") {
+                    break;
+                }
+                updateLines.push(currentLine);
+                index += 1;
+            }
+            operations.push({
+                type: "update",
+                path: targetPath,
+                move_to: moveTo,
+                hunks: parseUpdateHunks(updateLines),
+            });
+            continue;
+        }
+        throw new Error(`Nao reconheci a operacao do apply_patch: ${line}`);
+    }
+    throw new Error("O apply_patch nao encontrou o marcador *** End Patch.");
+}
+export function collectStructuredPatchTargets(patchText) {
+    try {
+        const parsed = parseStructuredPatch(patchText);
+        const targets = [];
+        const seen = new Set();
+        for (const operation of parsed.operations) {
+            const pushTarget = (targetPath, accessMode) => {
+                const key = `${accessMode}:${targetPath}`;
+                if (!targetPath || seen.has(key)) {
+                    return;
+                }
+                seen.add(key);
+                targets.push({ path: targetPath, accessMode });
+            };
+            if (operation.type === "add") {
+                pushTarget(operation.path, "write");
+                continue;
+            }
+            if (operation.type === "delete") {
+                pushTarget(operation.path, "delete");
+                continue;
+            }
+            pushTarget(operation.path, "write");
+            if (operation.move_to) {
+                pushTarget(operation.move_to, "write");
+            }
+        }
+        return targets;
+    }
+    catch {
+        return [];
+    }
+}
+export function structuredPatchHasDelete(patchText) {
+    return collectStructuredPatchTargets(patchText).some((item) => item.accessMode === "delete");
+}
+function splitTextForPatch(value) {
+    const normalized = normalizePatchText(value);
+    if (!normalized) {
+        return { lines: [], trailingNewline: false };
+    }
+    const trailingNewline = normalized.endsWith("\n");
+    const lines = normalized.split("\n");
+    if (trailingNewline) {
+        lines.pop();
+    }
+    return { lines, trailingNewline };
+}
+function joinPatchedText(lines, trailingNewline) {
+    if (lines.length === 0) {
+        return "";
+    }
+    return `${lines.join("\n")}${trailingNewline ? "\n" : ""}`;
+}
+function findMatchingSegment(lines, targetLines, startIndex) {
+    if (targetLines.length === 0) {
+        return startIndex;
+    }
+    for (let index = startIndex; index <= lines.length - targetLines.length; index += 1) {
+        let matches = true;
+        for (let offset = 0; offset < targetLines.length; offset += 1) {
+            if (lines[index + offset] !== targetLines[offset]) {
+                matches = false;
+                break;
+            }
+        }
+        if (matches) {
+            return index;
+        }
+    }
+    if (startIndex > 0) {
+        return findMatchingSegment(lines, targetLines, 0);
+    }
+    return -1;
+}
+export function applyStructuredUpdateToText(originalText, operation) {
+    const { lines, trailingNewline } = splitTextForPatch(originalText);
+    let cursor = 0;
+    let addedLineCount = 0;
+    let deletedLineCount = 0;
+    for (const hunk of operation.hunks) {
+        const oldLines = hunk.lines
+            .filter((line) => line.kind !== "add")
+            .map((line) => line.text);
+        const newLines = hunk.lines
+            .filter((line) => line.kind !== "delete")
+            .map((line) => line.text);
+        const matchIndex = oldLines.length === 0
+            ? cursor
+            : findMatchingSegment(lines, oldLines, cursor);
+        if (matchIndex < 0) {
+            throw new Error(`Nao consegui localizar o contexto do patch para ${operation.path}.`);
+        }
+        lines.splice(matchIndex, oldLines.length, ...newLines);
+        cursor = matchIndex + newLines.length;
+        addedLineCount += hunk.lines.filter((line) => line.kind === "add").length;
+        deletedLineCount += hunk.lines.filter((line) => line.kind === "delete").length;
+    }
+    return {
+        text: joinPatchedText(lines, trailingNewline),
+        addedLineCount,
+        deletedLineCount,
+    };
+}