report: attach the log lines the caller read

[rafaelfiguereod-stack]

Fixes #73.

The change

report's logs field becomes the lines to attach rather than a count of lines for the app to go and fetch:

-logs: z.int().min(0).optional().describe(`trailing app log entries to attach (0 to omit; default: ${ISSUE_LOG_TAIL})`),
+logs: z.array(z.string()).optional().describe("app log lines to attach, as read with the logs tool; omit to attach none"),

and the handler files what it was handed instead of re-reading the buffer:

-const tail = logs ?? ISSUE_LOG_TAIL;
-const lines = tail > 0 ? ctx.logs().slice(-tail).map(formatLogEntry) : [];
-const url = await createIssue(summary, buildIssueBody({ body, commands, logs: lines, version: ctx.version }));
+// The caller's lines, never the live buffer: what was read is what is filed.
+const url = await createIssue(summary, buildIssueBody({ body, commands, logs: logs ?? [], version: ctx.version }));

That makes the existing instruction in the description followable. Reading the logs first was already possible through the logs tool, but it did not guarantee much, because the tail was taken again inside report and the app keeps logging in between. Now there is only one read, and the caller did it.

I reworded the description to match, keeping the no review step sentence as you had it.

dapi report --logs n still works the same

The command makes the logs call itself and passes what comes back, so nothing changes for someone at a terminal. It also means dapi logs --tail n now shows exactly what an issue would carry, since it is the same call and the same formatting.

To get that, formatLogEntry moves from apps/desktop/src/dapi/handlers/logs.ts into packages/dapi/src/tools/logs.ts, beside the logs tool and the LogEntry schema it formats. Both the app and the CLI import it from there, so a line cannot drift between the two.

ISSUE_LOG_TAIL stays at 50 and is now the CLI's default rather than the handler's.

Verified

Windows 11, Node 24.1.0, Electron 43, on top of b317412.

• npm run check for dapi, desktop and cli: clean
• npm test --workspace=@diffusionstudio/dapi: 37 passed, up from 36, the new one covers the schema change
• npm run lint: unchanged, 0 errors and the same 3 pre-existing warnings
• End to end against a running app, with gh taken off the app's PATH so nothing could actually be filed: dapi report "..." --logs 2 made the logs call, passed the formatted lines, the handler accepted them and reached the gh step, which failed with the expected "gh is not installed" message. The lines matched dapi logs --tail 2 exactly.

I did not drive a real filing, for the obvious reason.

Unrelated, but noticed while verifying

On Windows, any dapi command that surfaces a tool error prints the error correctly and then aborts with Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 76. I reproduced it on unmodified main with dapi capture <unknown id> and dapi check <unknown id>, so it predates this branch and is not something this PR introduces or fixes. It looks like process.exit in fail() landing while the MCP transport still has a handle open. Happy to open a separate issue if useful.

🤖 Generated with Claude Code

[vercel]

@rafaelfiguereod-stack is attempting to deploy a commit to the Diffusion Studio Team on Vercel.

A member of the Team first needs to authorize it.