Yaver 0.9.65

Yaver 0.9.65

A follow-up comment on one merge request or pull request of a multi-repo job pushes only that repository and reuses that review. The other repositories stay local. A push of the shared folder fails, because that folder is not a git repository. A later run that names one repository drops the previous set, including when a schedule sends an empty list while the ticket text still names the old pair. A description that does not parse, and that does not send a repository list, leaves the stored set in place.

A comment on a review this job already opened stays on that issue when the title has no key or names a different ticket. Merging one review keeps the plan and the local issue until every review recorded on the job is merged or closed. A later job that uses the same repository, source, and target waits until the running job finishes.

Settings → Projects keeps the list you already saved until you choose Reload from tokens. Saving accepts the full imported list. You can search projects by name, select the visible rows, and delete that selection. Schedule and repo-set pickers find a saved repository by name or URL.

Analytics uses the width of the page. The breakdown tables keep their columns on screen, the jobs chart keeps a fixed height, and category mix sits with that chart. The standalone executable reads its agents from the folder beside the program.

Yaver 0.9.64

A dashboard job can work in every repository of a saved repo set, or in extra repositories you add on the schedule. Each repository keeps its own source and target, and Yaver pushes it and opens its own merge request. The job page and the issue page show each repository's commit and merge request. One repository on a schedule still runs as a single job. Mode, backend, and model sit with the repositories on the schedule form.

Repo sets and saved projects are lists. The plus button adds one, the pencil edits it in a popup, and the trash icon removes it. Opening Settings → Projects loads every Git repository the saved GitLab and Azure tokens can read, and a project you already saved keeps its label and branches. Azure DevOps Server is asked with API 7.1, then 7.0, 6.1, and 6.0, and a server without a collection-wide list is read one team project at a time. Search on a repo set and on a schedule filters those projects by name or URL.

A failed build still pushes and opens a merge request when this run moved that repository. Delivery and the queue use each repository's own branch, including branches written in the issue description. The shared folder stays until every merge request recorded on the job is merged or closed, and it also stays when you cancel a finished run. A later single-repo job does not resume the multi-repo chat. A rejected push names the repository, and a second push to the same merge request keeps the new commit.

Yaver 0.9.63

The Completed total on Analytics opens a jobs list that includes a finished plan, which is the same set that total already counts. Back to Analytics returns to the period you were viewing, and a custom range keeps the same from and to.

Yaver 0.9.62

Jobs, schedules, and saved sessions stay on the dashboard when the search index cannot rebuild, because Yaver reads the JSON files instead of an empty index.
Stopping a job and a worker finishing it no longer overwrite each other, so a cancelled queue row stays cancelled.
Scheduling that issue again starts a new job even when the old queue row was still marked running, and that run shows up in Jobs.
Opening the Queue tab loads the waiting rows immediately.
Saving projects in Settings keeps each repository's source branch.
A failed plan, after the ticket is sent back to To Do, no longer puts the implement label back on the ticket.
GitLab merge requests that do not name a Jira key now include the GitLab host in the fallback key, so two servers with the same project path no longer share one plan.
An Azure review of a file such as .github/workflows/ci.yml is posted on that file.
Cancelling a job removes the token from the clone's origin URL.
Installing OpenCode, Codex, or Claude Code renames the binary already on PATH with today's date and copies the new binary into that same directory.
Linux releases include yaver-clis-linux-x64, with the same three CLIs as the Windows CLI zip.
Jira answer comments name OpenCode, Codex, or Claude Code, and the dashboard no longer warns when the Jira poller is turned off.

Yaver 0.9.61

A Claude job that resumes an earlier run now shows that run's prompt and log in the transcript, then the short continue line and the new reply.
Choosing Claude in Settings lists the models served at ANTHROPIC_BASE_URL, and any model saved in Claude's own settings.
An API retry in the transcript shows the attempt count, the HTTP status, how long Claude will wait, and the request id when Claude sends one.
Jira, GitLab, and Azure comments name the backend, OpenCode, Codex, or Claude Code, on the same line as the version and model.
Opening a collapsed tool row in the transcript no longer traps the mouse wheel.

Yaver 0.9.60

Jira keys written in a job title or description, and on the issue page, now open that ticket on the configured Jira host.
A key that is already inside a URL stays as text, and GL- and AZ- ids stay as text because those are Yaver's own GitLab and Azure keys.
A new build ticket finds a plan that was saved for Claude on the same repository, source, and target.
A Claude result marked as an error is the text on the job and in the Jira comment, instead of a generic execution failure.
AskUserQuestion from the turn that was nudged does not make the next finish look like another question.
The Claude transcript keeps the sentence after a closed error object, keeps the message on a failed tool result, and shows each tool result on its own tool when one turn calls two tools.
Diagnostic zips redact Anthropic and Codex key values, the dashboard password, and an Authorization Basic header copied from the daemon log.

Yaver 0.9.59

Claude Code is now a third unattended worker beside OpenCode and Codex.
A plan, build, test, or review job can run claude in print mode with the derman agents, stream the transcript to the dashboard, and resume that same session later.
The dashboard shows Claude jobs in the worker views.
The offline CLI zip installs pinned OpenCode, Codex, and Claude Code, and install-agents copies the derman agents into both homes.
OpenCode, Codex, and Claude each keep their own session for the same repository, branch, target, and kind.
A Claude resume uses the Claude continue prompt, and the one follow-up after a question stays on that process.
A stream that goes silent is stopped, and the session id from the first line is kept so the next run can resume.
The reviewer agent cannot edit files or run a shell, and the cost on the Claude result line is stored on the job.
A plan command on an Azure work item is kept when the same save also changes state.
Jira comment paging continues while total says more comments remain.
A failed disk write no longer looks saved, a cancelled queue row stays cancelled, and Analytics search treats percent and underscore as literal text.
If the SQLite index write fails, Jobs, schedules, and sessions read the JSON files.
Diagnostic zips redact environment names that contain KEY, including CODEX_API_KEY.
Job transcripts can be read from the legacy .jira-agent folder.
Azure Boards jobs are labeled Azure Boards, a Claude user line is labeled You, and a multiline Claude reply is one transcript row.

Yaver 0.9.58

A failed push used to leave unpushed commits and dirty files in the reused clone, so the next push was rejected.
Yaver now hard-resets that work tree before the next job, fetches the remote branch when it exists, and recreates the branch from the target when it does not.

Yaver 0.9.57

Implement and Revise on a plan-ready job write the same Jira label or Azure work-item comment the poller and webhook already accept, and the next poll does the work.
Revise after Implement removes plan_execute as well as plan_ready, so the next poll revises instead of starting the build.
Only the newest job for a ticket shows Plan ready. Older plan rows say Superseded.
The current plan file is a Plan tab on that job, in the same row as Prompt.
If that revision fails, Revise stays on the latest error plan job. It reopens the ticket to plan_ready and queues another revision from the plan file still on disk.
A missing {params} block no longer says the ticket moved to In Progress when the board stayed on To Do.
Invalid Mode errors list plan, build, and test.
On Windows, a client that disappears during accept no longer closes port 8080. The poller keeps running and the dashboard accepts the next connection.

Yaver 0.9.56

Scheduled and Sessions now use a local SQLite index, the same way Jobs does.
schedules.sqlite and opencode-binds.sqlite are created on first start, including when the JSON files are already there.
The JSON files remain the full record, and the Sessions page lists every live bind.

Looking up an existing issue fills repository, source, target, and mode in the same fields as a new issue.
The prompt box shows the ticket text without the {params} block.
Schedule or Run now writes those fields back to Jira only when you change them.
The source choice is labeled custom branch.

Hovering a dot on the Analytics jobs chart shows the time bucket and the exact count for every series that is turned on.

When a merge request cannot be created, the job log and the Jira comment include the remote status and the server message.
Submodules are updated after the work branch is checked out, so the pins match the branch the job edits.

Yaver 0.9.55

Analytics and the Jobs list read a local SQLite index next to the job files. The index is created on first start, including for a data directory that already has months of job JSON. The visible Jobs page still opens those files, so error text and ...

Yaver 0.9.64

Yaver 0.9.64

A dashboard job can work in every repository of a saved repo set, or in extra repositories you add on the schedule. Each repository keeps its own source and target, and Yaver pushes it and opens its own merge request. The job page and the issue page show each repository's commit and merge request. One repository on a schedule still runs as a single job. Mode, backend, and model sit with the repositories on the schedule form.

Repo sets and saved projects are lists. The plus button adds one, the pencil edits it in a popup, and the trash icon removes it. Opening Settings → Projects loads every Git repository the saved GitLab and Azure tokens can read, and a project you already saved keeps its label and branches. Azure DevOps Server is asked with API 7.1, then 7.0, 6.1, and 6.0, and a server without a collection-wide list is read one team project at a time. Search on a repo set and on a schedule filters those projects by name or URL.

A failed build still pushes and opens a merge request when this run moved that repository. Delivery and the queue use each repository's own branch, including branches written in the issue description. The shared folder stays until every merge request recorded on the job is merged or closed, and it also stays when you cancel a finished run. A later single-repo job does not resume the multi-repo chat. A rejected push names the repository, and a second push to the same merge request keeps the new commit.

Yaver 0.9.63

The Completed total on Analytics opens a jobs list that includes a finished plan, which is the same set that total already counts. Back to Analytics returns to the period you were viewing, and a custom range keeps the same from and to.

Yaver 0.9.62

Jobs, schedules, and saved sessions stay on the dashboard when the search index cannot rebuild, because Yaver reads the JSON files instead of an empty index.
Stopping a job and a worker finishing it no longer overwrite each other, so a cancelled queue row stays cancelled.
Scheduling that issue again starts a new job even when the old queue row was still marked running, and that run shows up in Jobs.
Opening the Queue tab loads the waiting rows immediately.
Saving projects in Settings keeps each repository's source branch.
A failed plan, after the ticket is sent back to To Do, no longer puts the implement label back on the ticket.
GitLab merge requests that do not name a Jira key now include the GitLab host in the fallback key, so two servers with the same project path no longer share one plan.
An Azure review of a file such as .github/workflows/ci.yml is posted on that file.
Cancelling a job removes the token from the clone's origin URL.
Installing OpenCode, Codex, or Claude Code renames the binary already on PATH with today's date and copies the new binary into that same directory.
Linux releases include yaver-clis-linux-x64, with the same three CLIs as the Windows CLI zip.
Jira answer comments name OpenCode, Codex, or Claude Code, and the dashboard no longer warns when the Jira poller is turned off.

Yaver 0.9.61

A Claude job that resumes an earlier run now shows that run's prompt and log in the transcript, then the short continue line and the new reply.
Choosing Claude in Settings lists the models served at ANTHROPIC_BASE_URL, and any model saved in Claude's own settings.
An API retry in the transcript shows the attempt count, the HTTP status, how long Claude will wait, and the request id when Claude sends one.
Jira, GitLab, and Azure comments name the backend, OpenCode, Codex, or Claude Code, on the same line as the version and model.
Opening a collapsed tool row in the transcript no longer traps the mouse wheel.

Yaver 0.9.60

Jira keys written in a job title or description, and on the issue page, now open that ticket on the configured Jira host.
A key that is already inside a URL stays as text, and GL- and AZ- ids stay as text because those are Yaver's own GitLab and Azure keys.
A new build ticket finds a plan that was saved for Claude on the same repository, source, and target.
A Claude result marked as an error is the text on the job and in the Jira comment, instead of a generic execution failure.
AskUserQuestion from the turn that was nudged does not make the next finish look like another question.
The Claude transcript keeps the sentence after a closed error object, keeps the message on a failed tool result, and shows each tool result on its own tool when one turn calls two tools.
Diagnostic zips redact Anthropic and Codex key values, the dashboard password, and an Authorization Basic header copied from the daemon log.

Yaver 0.9.59

Claude Code is now a third unattended worker beside OpenCode and Codex.
A plan, build, test, or review job can run claude in print mode with the derman agents, stream the transcript to the dashboard, and resume that same session later.
The dashboard shows Claude jobs in the worker views.
The offline CLI zip installs pinned OpenCode, Codex, and Claude Code, and install-agents copies the derman agents into both homes.
OpenCode, Codex, and Claude each keep their own session for the same repository, branch, target, and kind.
A Claude resume uses the Claude continue prompt, and the one follow-up after a question stays on that process.
A stream that goes silent is stopped, and the session id from the first line is kept so the next run can resume.
The reviewer agent cannot edit files or run a shell, and the cost on the Claude result line is stored on the job.
A plan command on an Azure work item is kept when the same save also changes state.
Jira comment paging continues while total says more comments remain.
A failed disk write no longer looks saved, a cancelled queue row stays cancelled, and Analytics search treats percent and underscore as literal text.
If the SQLite index write fails, Jobs, schedules, and sessions read the JSON files.
Diagnostic zips redact environment names that contain KEY, including CODEX_API_KEY.
Job transcripts can be read from the legacy .jira-agent folder.
Azure Boards jobs are labeled Azure Boards, a Claude user line is labeled You, and a multiline Claude reply is one transcript row.

Yaver 0.9.58

A failed push used to leave unpushed commits and dirty files in the reused clone, so the next push was rejected.
Yaver now hard-resets that work tree before the next job, fetches the remote branch when it exists, and recreates the branch from the target when it does not.

Yaver 0.9.57

Implement and Revise on a plan-ready job write the same Jira label or Azure work-item comment the poller and webhook already accept, and the next poll does the work.
Revise after Implement removes plan_execute as well as plan_ready, so the next poll revises instead of starting the build.
Only the newest job for a ticket shows Plan ready. Older plan rows say Superseded.
The current plan file is a Plan tab on that job, in the same row as Prompt.
If that revision fails, Revise stays on the latest error plan job. It reopens the ticket to plan_ready and queues another revision from the plan file still on disk.
A missing {params} block no longer says the ticket moved to In Progress when the board stayed on To Do.
Invalid Mode errors list plan, build, and test.
On Windows, a client that disappears during accept no longer closes port 8080. The poller keeps running and the dashboard accepts the next connection.

Yaver 0.9.56

Scheduled and Sessions now use a local SQLite index, the same way Jobs does.
schedules.sqlite and opencode-binds.sqlite are created on first start, including when the JSON files are already there.
The JSON files remain the full record, and the Sessions page lists every live bind.

Looking up an existing issue fills repository, source, target, and mode in the same fields as a new issue.
The prompt box shows the ticket text without the {params} block.
Schedule or Run now writes those fields back to Jira only when you change them.
The source choice is labeled custom branch.

Hovering a dot on the Analytics jobs chart shows the time bucket and the exact count for every series that is turned on.

When a merge request cannot be created, the job log and the Jira comment include the remote status and the server message.
Submodules are updated after the work branch is checked out, so the pins match the branch the job edits.

Yaver 0.9.55

Analytics and the Jobs list read a local SQLite index next to the job files. The index is created on first start, including for a data directory that already has months of job JSON. The visible Jobs page still opens those files, so error text and the session id stay on the list.

Storage is one folder, YAVER_BASE_DIR. The default is %LOCALAPPDATA%\Yaver on Windows and ~/.local/share/yaver on Linux. Data is {base}/yaver and clones are {base}/t. An existing YAVER_DATA_DIR or TEMP_DIR_BASE still wins for that path.

The chart step follows the time range. There is no separate Hour, Day, Week, or Month control. The mark is phosphor green, and the in-app wink is larger.

Yaver 0.9.54

A GitLab review keeps the overview comment on the merge request when an inline finding cannot be posted. That skip is logged, and it no longer fails the whole MR job. Linux install and start scripts are stored with LF line endings, so WSL bash can run them.

Yaver 0.9.53

Analytics splits merge requests Yaver opened from ones it only commented on. Open, Merged, and Closed cards go to a list of the unique MR and PR links. Counts are split into Opened by us (Jira or Azure Boards) and Contributed (a comment on an existing GitLab MR or Azure PR). Review and build jobs on the same URL still count once. Search and Issue key filters are gone from Analytics.

Yaver 0.9.52

Selected code on a GitLab or Azure review comment reaches the agent. An inline /yaver, /review, or /ask on a selected range puts the file, the lines, and a clone snippet in the prompt. A reply on that thread loads the original range and the earlier notes. Azure PR ...

Yaver 0.9.63

Yaver 0.9.63

The Completed total on Analytics opens a jobs list that includes a finished plan, which is the same set that total already counts. Back to Analytics returns to the period you were viewing, and a custom range keeps the same from and to.

Yaver 0.9.62

Jobs, schedules, and saved sessions stay on the dashboard when the search index cannot rebuild, because Yaver reads the JSON files instead of an empty index.
Stopping a job and a worker finishing it no longer overwrite each other, so a cancelled queue row stays cancelled.
Scheduling that issue again starts a new job even when the old queue row was still marked running, and that run shows up in Jobs.
Opening the Queue tab loads the waiting rows immediately.
Saving projects in Settings keeps each repository's source branch.
A failed plan, after the ticket is sent back to To Do, no longer puts the implement label back on the ticket.
GitLab merge requests that do not name a Jira key now include the GitLab host in the fallback key, so two servers with the same project path no longer share one plan.
An Azure review of a file such as .github/workflows/ci.yml is posted on that file.
Cancelling a job removes the token from the clone's origin URL.
Installing OpenCode, Codex, or Claude Code renames the binary already on PATH with today's date and copies the new binary into that same directory.
Linux releases include yaver-clis-linux-x64, with the same three CLIs as the Windows CLI zip.
Jira answer comments name OpenCode, Codex, or Claude Code, and the dashboard no longer warns when the Jira poller is turned off.

Yaver 0.9.61

A Claude job that resumes an earlier run now shows that run's prompt and log in the transcript, then the short continue line and the new reply.
Choosing Claude in Settings lists the models served at ANTHROPIC_BASE_URL, and any model saved in Claude's own settings.
An API retry in the transcript shows the attempt count, the HTTP status, how long Claude will wait, and the request id when Claude sends one.
Jira, GitLab, and Azure comments name the backend, OpenCode, Codex, or Claude Code, on the same line as the version and model.
Opening a collapsed tool row in the transcript no longer traps the mouse wheel.

Yaver 0.9.60

Jira keys written in a job title or description, and on the issue page, now open that ticket on the configured Jira host.
A key that is already inside a URL stays as text, and GL- and AZ- ids stay as text because those are Yaver's own GitLab and Azure keys.
A new build ticket finds a plan that was saved for Claude on the same repository, source, and target.
A Claude result marked as an error is the text on the job and in the Jira comment, instead of a generic execution failure.
AskUserQuestion from the turn that was nudged does not make the next finish look like another question.
The Claude transcript keeps the sentence after a closed error object, keeps the message on a failed tool result, and shows each tool result on its own tool when one turn calls two tools.
Diagnostic zips redact Anthropic and Codex key values, the dashboard password, and an Authorization Basic header copied from the daemon log.

Yaver 0.9.59

Claude Code is now a third unattended worker beside OpenCode and Codex.
A plan, build, test, or review job can run claude in print mode with the derman agents, stream the transcript to the dashboard, and resume that same session later.
The dashboard shows Claude jobs in the worker views.
The offline CLI zip installs pinned OpenCode, Codex, and Claude Code, and install-agents copies the derman agents into both homes.
OpenCode, Codex, and Claude each keep their own session for the same repository, branch, target, and kind.
A Claude resume uses the Claude continue prompt, and the one follow-up after a question stays on that process.
A stream that goes silent is stopped, and the session id from the first line is kept so the next run can resume.
The reviewer agent cannot edit files or run a shell, and the cost on the Claude result line is stored on the job.
A plan command on an Azure work item is kept when the same save also changes state.
Jira comment paging continues while total says more comments remain.
A failed disk write no longer looks saved, a cancelled queue row stays cancelled, and Analytics search treats percent and underscore as literal text.
If the SQLite index write fails, Jobs, schedules, and sessions read the JSON files.
Diagnostic zips redact environment names that contain KEY, including CODEX_API_KEY.
Job transcripts can be read from the legacy .jira-agent folder.
Azure Boards jobs are labeled Azure Boards, a Claude user line is labeled You, and a multiline Claude reply is one transcript row.

Yaver 0.9.58

A failed push used to leave unpushed commits and dirty files in the reused clone, so the next push was rejected.
Yaver now hard-resets that work tree before the next job, fetches the remote branch when it exists, and recreates the branch from the target when it does not.

Yaver 0.9.57

Implement and Revise on a plan-ready job write the same Jira label or Azure work-item comment the poller and webhook already accept, and the next poll does the work.
Revise after Implement removes plan_execute as well as plan_ready, so the next poll revises instead of starting the build.
Only the newest job for a ticket shows Plan ready. Older plan rows say Superseded.
The current plan file is a Plan tab on that job, in the same row as Prompt.
If that revision fails, Revise stays on the latest error plan job. It reopens the ticket to plan_ready and queues another revision from the plan file still on disk.
A missing {params} block no longer says the ticket moved to In Progress when the board stayed on To Do.
Invalid Mode errors list plan, build, and test.
On Windows, a client that disappears during accept no longer closes port 8080. The poller keeps running and the dashboard accepts the next connection.

Yaver 0.9.56

Scheduled and Sessions now use a local SQLite index, the same way Jobs does.
schedules.sqlite and opencode-binds.sqlite are created on first start, including when the JSON files are already there.
The JSON files remain the full record, and the Sessions page lists every live bind.

Looking up an existing issue fills repository, source, target, and mode in the same fields as a new issue.
The prompt box shows the ticket text without the {params} block.
Schedule or Run now writes those fields back to Jira only when you change them.
The source choice is labeled custom branch.

Hovering a dot on the Analytics jobs chart shows the time bucket and the exact count for every series that is turned on.

When a merge request cannot be created, the job log and the Jira comment include the remote status and the server message.
Submodules are updated after the work branch is checked out, so the pins match the branch the job edits.

Yaver 0.9.55

Analytics and the Jobs list read a local SQLite index next to the job files. The index is created on first start, including for a data directory that already has months of job JSON. The visible Jobs page still opens those files, so error text and the session id stay on the list.

Storage is one folder, YAVER_BASE_DIR. The default is %LOCALAPPDATA%\Yaver on Windows and ~/.local/share/yaver on Linux. Data is {base}/yaver and clones are {base}/t. An existing YAVER_DATA_DIR or TEMP_DIR_BASE still wins for that path.

The chart step follows the time range. There is no separate Hour, Day, Week, or Month control. The mark is phosphor green, and the in-app wink is larger.

Yaver 0.9.54

A GitLab review keeps the overview comment on the merge request when an inline finding cannot be posted. That skip is logged, and it no longer fails the whole MR job. Linux install and start scripts are stored with LF line endings, so WSL bash can run them.

Yaver 0.9.53

Analytics splits merge requests Yaver opened from ones it only commented on. Open, Merged, and Closed cards go to a list of the unique MR and PR links. Counts are split into Opened by us (Jira or Azure Boards) and Contributed (a comment on an existing GitLab MR or Azure PR). Review and build jobs on the same URL still count once. Search and Issue key filters are gone from Analytics.

Yaver 0.9.52

Selected code on a GitLab or Azure review comment reaches the agent. An inline /yaver, /review, or /ask on a selected range puts the file, the lines, and a clone snippet in the prompt. A reply on that thread loads the original range and the earlier notes. Azure PR file-thread comments load the file, lines, and parent comments from the thread API, because the webhook does not send them. The Scheduled list pages the same way Jobs does, 25 rows at a time. Analytics shows Open, Merged, Closed, and Total cards for unique merge requests stored on the jobs.

Yaver 0.9.51

A second GitLab /yaver on the same merge request no longer fails to push. The queued follow-up fetches the first job's push and rebases onto it before delivering, so the local branch does not stay behind origin (tip of your current branch is behind).

Yaver 0.9.50

Analytics no longer hangs when the page refreshes or a chart request is slow. A live tick does not abort an Analytics GET that is already running. Changing the period or the filters still cancels the previous request. The daemon stops a cancelled walk and returns 504 if aggregation takes longer than 55 seconds. Issue key is an exact match, so KAN-24 does not include KAN-240. Search still matches a substring, and several keys can be separated by commas. Azure /yaver on a plan_ready ticket posts the same wait note GitLab already posts on the MR. Implement still waits for plan_execute. Plan ready and in flight show up on the cards, the chart, and the tables. Repository URLs with or without .git count as one repo. Jobs with no model appear as (unset) so the shares add up to 100%. There is a By agent table and a repository filter. A custom range copies the current fro...

Yaver 0.9.62

Yaver 0.9.62

Jobs, schedules, and saved sessions stay on the dashboard when the search index cannot rebuild, because Yaver reads the JSON files instead of an empty index.
Stopping a job and a worker finishing it no longer overwrite each other, so a cancelled queue row stays cancelled.
Scheduling that issue again starts a new job even when the old queue row was still marked running, and that run shows up in Jobs.
Opening the Queue tab loads the waiting rows immediately.
Saving projects in Settings keeps each repository's source branch.
A failed plan, after the ticket is sent back to To Do, no longer puts the implement label back on the ticket.
GitLab merge requests that do not name a Jira key now include the GitLab host in the fallback key, so two servers with the same project path no longer share one plan.
An Azure review of a file such as .github/workflows/ci.yml is posted on that file.
Cancelling a job removes the token from the clone's origin URL.
Installing OpenCode, Codex, or Claude Code renames the binary already on PATH with today's date and copies the new binary into that same directory.
Linux releases include yaver-clis-linux-x64, with the same three CLIs as the Windows CLI zip.
Jira answer comments name OpenCode, Codex, or Claude Code, and the dashboard no longer warns when the Jira poller is turned off.

Yaver 0.9.61

A Claude job that resumes an earlier run now shows that run's prompt and log in the transcript, then the short continue line and the new reply.
Choosing Claude in Settings lists the models served at ANTHROPIC_BASE_URL, and any model saved in Claude's own settings.
An API retry in the transcript shows the attempt count, the HTTP status, how long Claude will wait, and the request id when Claude sends one.
Jira, GitLab, and Azure comments name the backend, OpenCode, Codex, or Claude Code, on the same line as the version and model.
Opening a collapsed tool row in the transcript no longer traps the mouse wheel.

Yaver 0.9.60

Jira keys written in a job title or description, and on the issue page, now open that ticket on the configured Jira host.
A key that is already inside a URL stays as text, and GL- and AZ- ids stay as text because those are Yaver's own GitLab and Azure keys.
A new build ticket finds a plan that was saved for Claude on the same repository, source, and target.
A Claude result marked as an error is the text on the job and in the Jira comment, instead of a generic execution failure.
AskUserQuestion from the turn that was nudged does not make the next finish look like another question.
The Claude transcript keeps the sentence after a closed error object, keeps the message on a failed tool result, and shows each tool result on its own tool when one turn calls two tools.
Diagnostic zips redact Anthropic and Codex key values, the dashboard password, and an Authorization Basic header copied from the daemon log.

Yaver 0.9.59

Claude Code is now a third unattended worker beside OpenCode and Codex.
A plan, build, test, or review job can run claude in print mode with the derman agents, stream the transcript to the dashboard, and resume that same session later.
The dashboard shows Claude jobs in the worker views.
The offline CLI zip installs pinned OpenCode, Codex, and Claude Code, and install-agents copies the derman agents into both homes.
OpenCode, Codex, and Claude each keep their own session for the same repository, branch, target, and kind.
A Claude resume uses the Claude continue prompt, and the one follow-up after a question stays on that process.
A stream that goes silent is stopped, and the session id from the first line is kept so the next run can resume.
The reviewer agent cannot edit files or run a shell, and the cost on the Claude result line is stored on the job.
A plan command on an Azure work item is kept when the same save also changes state.
Jira comment paging continues while total says more comments remain.
A failed disk write no longer looks saved, a cancelled queue row stays cancelled, and Analytics search treats percent and underscore as literal text.
If the SQLite index write fails, Jobs, schedules, and sessions read the JSON files.
Diagnostic zips redact environment names that contain KEY, including CODEX_API_KEY.
Job transcripts can be read from the legacy .jira-agent folder.
Azure Boards jobs are labeled Azure Boards, a Claude user line is labeled You, and a multiline Claude reply is one transcript row.

Yaver 0.9.58

A failed push used to leave unpushed commits and dirty files in the reused clone, so the next push was rejected.
Yaver now hard-resets that work tree before the next job, fetches the remote branch when it exists, and recreates the branch from the target when it does not.

Yaver 0.9.57

Implement and Revise on a plan-ready job write the same Jira label or Azure work-item comment the poller and webhook already accept, and the next poll does the work.
Revise after Implement removes plan_execute as well as plan_ready, so the next poll revises instead of starting the build.
Only the newest job for a ticket shows Plan ready. Older plan rows say Superseded.
The current plan file is a Plan tab on that job, in the same row as Prompt.
If that revision fails, Revise stays on the latest error plan job. It reopens the ticket to plan_ready and queues another revision from the plan file still on disk.
A missing {params} block no longer says the ticket moved to In Progress when the board stayed on To Do.
Invalid Mode errors list plan, build, and test.
On Windows, a client that disappears during accept no longer closes port 8080. The poller keeps running and the dashboard accepts the next connection.

Yaver 0.9.56

Scheduled and Sessions now use a local SQLite index, the same way Jobs does.
schedules.sqlite and opencode-binds.sqlite are created on first start, including when the JSON files are already there.
The JSON files remain the full record, and the Sessions page lists every live bind.

Looking up an existing issue fills repository, source, target, and mode in the same fields as a new issue.
The prompt box shows the ticket text without the {params} block.
Schedule or Run now writes those fields back to Jira only when you change them.
The source choice is labeled custom branch.

Hovering a dot on the Analytics jobs chart shows the time bucket and the exact count for every series that is turned on.

When a merge request cannot be created, the job log and the Jira comment include the remote status and the server message.
Submodules are updated after the work branch is checked out, so the pins match the branch the job edits.

Yaver 0.9.55

Analytics and the Jobs list read a local SQLite index next to the job files. The index is created on first start, including for a data directory that already has months of job JSON. The visible Jobs page still opens those files, so error text and the session id stay on the list.

Storage is one folder, YAVER_BASE_DIR. The default is %LOCALAPPDATA%\Yaver on Windows and ~/.local/share/yaver on Linux. Data is {base}/yaver and clones are {base}/t. An existing YAVER_DATA_DIR or TEMP_DIR_BASE still wins for that path.

The chart step follows the time range. There is no separate Hour, Day, Week, or Month control. The mark is phosphor green, and the in-app wink is larger.

Yaver 0.9.54

A GitLab review keeps the overview comment on the merge request when an inline finding cannot be posted. That skip is logged, and it no longer fails the whole MR job. Linux install and start scripts are stored with LF line endings, so WSL bash can run them.

Yaver 0.9.53

Analytics splits merge requests Yaver opened from ones it only commented on. Open, Merged, and Closed cards go to a list of the unique MR and PR links. Counts are split into Opened by us (Jira or Azure Boards) and Contributed (a comment on an existing GitLab MR or Azure PR). Review and build jobs on the same URL still count once. Search and Issue key filters are gone from Analytics.

Yaver 0.9.52

Selected code on a GitLab or Azure review comment reaches the agent. An inline /yaver, /review, or /ask on a selected range puts the file, the lines, and a clone snippet in the prompt. A reply on that thread loads the original range and the earlier notes. Azure PR file-thread comments load the file, lines, and parent comments from the thread API, because the webhook does not send them. The Scheduled list pages the same way Jobs does, 25 rows at a time. Analytics shows Open, Merged, Closed, and Total cards for unique merge requests stored on the jobs.

Yaver 0.9.51

A second GitLab /yaver on the same merge request no longer fails to push. The queued follow-up fetches the first job's push and rebases onto it before delivering, so the local branch does not stay behind origin (tip of your current branch is behind).

Yaver 0.9.50

Analytics no longer hangs when the page refreshes or a chart request is slow. A live tick does not abort an Analytics GET that is already running. Changing the period or the filters still cancels the previous request. The daemon stops a cancelled walk and returns 504 if aggregation takes longer than 55 seconds. Issue key is an exact match, so KAN-24 does not include KAN-240. Search still matches a substring, and several keys can be separated by commas. Azure /yaver on a plan_ready ticket posts the same wait note GitLab already posts on the MR. Implement still waits for plan_execute. Plan ready and in flight show up on the cards, the chart, and the tables. Repository URLs with or without .git count as one repo. Jobs with no model appear as (unset) so the shares add up to 100%. There is a By agent table and a repository filter. A custom range copies the current from and to dates instead of jumping to all time. GET /api/analytics runs off the event loop, so Jobs and Stop stay responsive.

Yaver 0.9.49

Analytics no longer times out when you change the chart bucket. Switching the period or the bucket, for examp...

Yaver 0.9.61

Yaver 0.9.61

A Claude job that resumes an earlier run now shows that run's prompt and log in the transcript, then the short continue line and the new reply.
Choosing Claude in Settings lists the models served at ANTHROPIC_BASE_URL, and any model saved in Claude's own settings.
An API retry in the transcript shows the attempt count, the HTTP status, how long Claude will wait, and the request id when Claude sends one.
Jira, GitLab, and Azure comments name the backend, OpenCode, Codex, or Claude Code, on the same line as the version and model.
Opening a collapsed tool row in the transcript no longer traps the mouse wheel.

Yaver 0.9.60

Jira keys written in a job title or description, and on the issue page, now open that ticket on the configured Jira host.
A key that is already inside a URL stays as text, and GL- and AZ- ids stay as text because those are Yaver's own GitLab and Azure keys.
A new build ticket finds a plan that was saved for Claude on the same repository, source, and target.
A Claude result marked as an error is the text on the job and in the Jira comment, instead of a generic execution failure.
AskUserQuestion from the turn that was nudged does not make the next finish look like another question.
The Claude transcript keeps the sentence after a closed error object, keeps the message on a failed tool result, and shows each tool result on its own tool when one turn calls two tools.
Diagnostic zips redact Anthropic and Codex key values, the dashboard password, and an Authorization Basic header copied from the daemon log.

Yaver 0.9.59

Claude Code is now a third unattended worker beside OpenCode and Codex.
A plan, build, test, or review job can run claude in print mode with the derman agents, stream the transcript to the dashboard, and resume that same session later.
The dashboard shows Claude jobs in the worker views.
The offline CLI zip installs pinned OpenCode, Codex, and Claude Code, and install-agents copies the derman agents into both homes.
OpenCode, Codex, and Claude each keep their own session for the same repository, branch, target, and kind.
A Claude resume uses the Claude continue prompt, and the one follow-up after a question stays on that process.
A stream that goes silent is stopped, and the session id from the first line is kept so the next run can resume.
The reviewer agent cannot edit files or run a shell, and the cost on the Claude result line is stored on the job.
A plan command on an Azure work item is kept when the same save also changes state.
Jira comment paging continues while total says more comments remain.
A failed disk write no longer looks saved, a cancelled queue row stays cancelled, and Analytics search treats percent and underscore as literal text.
If the SQLite index write fails, Jobs, schedules, and sessions read the JSON files.
Diagnostic zips redact environment names that contain KEY, including CODEX_API_KEY.
Job transcripts can be read from the legacy .jira-agent folder.
Azure Boards jobs are labeled Azure Boards, a Claude user line is labeled You, and a multiline Claude reply is one transcript row.

Yaver 0.9.58

A failed push used to leave unpushed commits and dirty files in the reused clone, so the next push was rejected.
Yaver now hard-resets that work tree before the next job, fetches the remote branch when it exists, and recreates the branch from the target when it does not.

Yaver 0.9.57

Implement and Revise on a plan-ready job write the same Jira label or Azure work-item comment the poller and webhook already accept, and the next poll does the work.
Revise after Implement removes plan_execute as well as plan_ready, so the next poll revises instead of starting the build.
Only the newest job for a ticket shows Plan ready. Older plan rows say Superseded.
The current plan file is a Plan tab on that job, in the same row as Prompt.
If that revision fails, Revise stays on the latest error plan job. It reopens the ticket to plan_ready and queues another revision from the plan file still on disk.
A missing {params} block no longer says the ticket moved to In Progress when the board stayed on To Do.
Invalid Mode errors list plan, build, and test.
On Windows, a client that disappears during accept no longer closes port 8080. The poller keeps running and the dashboard accepts the next connection.

Yaver 0.9.56

Scheduled and Sessions now use a local SQLite index, the same way Jobs does.
schedules.sqlite and opencode-binds.sqlite are created on first start, including when the JSON files are already there.
The JSON files remain the full record, and the Sessions page lists every live bind.

Looking up an existing issue fills repository, source, target, and mode in the same fields as a new issue.
The prompt box shows the ticket text without the {params} block.
Schedule or Run now writes those fields back to Jira only when you change them.
The source choice is labeled custom branch.

Hovering a dot on the Analytics jobs chart shows the time bucket and the exact count for every series that is turned on.

When a merge request cannot be created, the job log and the Jira comment include the remote status and the server message.
Submodules are updated after the work branch is checked out, so the pins match the branch the job edits.

Yaver 0.9.55

Analytics and the Jobs list read a local SQLite index next to the job files. The index is created on first start, including for a data directory that already has months of job JSON. The visible Jobs page still opens those files, so error text and the session id stay on the list.

Storage is one folder, YAVER_BASE_DIR. The default is %LOCALAPPDATA%\Yaver on Windows and ~/.local/share/yaver on Linux. Data is {base}/yaver and clones are {base}/t. An existing YAVER_DATA_DIR or TEMP_DIR_BASE still wins for that path.

The chart step follows the time range. There is no separate Hour, Day, Week, or Month control. The mark is phosphor green, and the in-app wink is larger.

Yaver 0.9.54

A GitLab review keeps the overview comment on the merge request when an inline finding cannot be posted. That skip is logged, and it no longer fails the whole MR job. Linux install and start scripts are stored with LF line endings, so WSL bash can run them.

Yaver 0.9.53

Analytics splits merge requests Yaver opened from ones it only commented on. Open, Merged, and Closed cards go to a list of the unique MR and PR links. Counts are split into Opened by us (Jira or Azure Boards) and Contributed (a comment on an existing GitLab MR or Azure PR). Review and build jobs on the same URL still count once. Search and Issue key filters are gone from Analytics.

Yaver 0.9.52

Selected code on a GitLab or Azure review comment reaches the agent. An inline /yaver, /review, or /ask on a selected range puts the file, the lines, and a clone snippet in the prompt. A reply on that thread loads the original range and the earlier notes. Azure PR file-thread comments load the file, lines, and parent comments from the thread API, because the webhook does not send them. The Scheduled list pages the same way Jobs does, 25 rows at a time. Analytics shows Open, Merged, Closed, and Total cards for unique merge requests stored on the jobs.

Yaver 0.9.51

A second GitLab /yaver on the same merge request no longer fails to push. The queued follow-up fetches the first job's push and rebases onto it before delivering, so the local branch does not stay behind origin (tip of your current branch is behind).

Yaver 0.9.50

Analytics no longer hangs when the page refreshes or a chart request is slow. A live tick does not abort an Analytics GET that is already running. Changing the period or the filters still cancels the previous request. The daemon stops a cancelled walk and returns 504 if aggregation takes longer than 55 seconds. Issue key is an exact match, so KAN-24 does not include KAN-240. Search still matches a substring, and several keys can be separated by commas. Azure /yaver on a plan_ready ticket posts the same wait note GitLab already posts on the MR. Implement still waits for plan_execute. Plan ready and in flight show up on the cards, the chart, and the tables. Repository URLs with or without .git count as one repo. Jobs with no model appear as (unset) so the shares add up to 100%. There is a By agent table and a repository filter. A custom range copies the current from and to dates instead of jumping to all time. GET /api/analytics runs off the event loop, so Jobs and Stop stay responsive.

Yaver 0.9.49

Analytics no longer times out when you change the chart bucket. Switching the period or the bucket, for example from 24 hours to Month, cancels the previous Analytics GET instead of showing Request timed out. The request budget is 60 seconds. The bucket series is capped so a coarse bucket cannot hang the handler.

Yaver 0.9.48

The dashboard has an Analytics page at /analytics. It charts job counts over time and can filter by status, model, category, source, and more. When a GitLab MR or an Azure PR is merged or closed, Yaver still deletes the clone, the session logs, and the OpenCode rows, and it keeps job_*.json so Analytics can count those runs. Deleting a row from Jobs still removes it. /review and /ask no longer reset a ticket that is waiting at plan_ready. They rebind onto a synthetic GL or AZ key. A failed plan_execute stays retryable. The label is not renamed to plan_executed before implement finishes.

Yaver 0.9.47

On Windows, Storage Delete and merged-review clone cleanup no longer follow the .yaver-plans junction into {YAVER_DATA_DIR}/plans. Deleting one clone no longer deletes plan files that belong to other tickets.

Yaver 0.9.46

When a GitLab MR or an Azure PR is merged or closed, Yaver also deletes that review's jobs, session logs, plan file, issue state, and OpenCode session rows. The shared daemon log is kept, and a job that is still running is skipped. After each OpenCode `GET /sess...

Yaver 0.9.60

Yaver 0.9.60

Jira keys written in a job title or description, and on the issue page, now open that ticket on the configured Jira host.
A key that is already inside a URL stays as text, and GL- and AZ- ids stay as text because those are Yaver's own GitLab and Azure keys.
A new build ticket finds a plan that was saved for Claude on the same repository, source, and target.
A Claude result marked as an error is the text on the job and in the Jira comment, instead of a generic execution failure.
AskUserQuestion from the turn that was nudged does not make the next finish look like another question.
The Claude transcript keeps the sentence after a closed error object, keeps the message on a failed tool result, and shows each tool result on its own tool when one turn calls two tools.
Diagnostic zips redact Anthropic and Codex key values, the dashboard password, and an Authorization Basic header copied from the daemon log.

Yaver 0.9.59

Claude Code is now a third unattended worker beside OpenCode and Codex.
A plan, build, test, or review job can run claude in print mode with the derman agents, stream the transcript to the dashboard, and resume that same session later.
The dashboard shows Claude jobs in the worker views.
The offline CLI zip installs pinned OpenCode, Codex, and Claude Code, and install-agents copies the derman agents into both homes.
OpenCode, Codex, and Claude each keep their own session for the same repository, branch, target, and kind.
A Claude resume uses the Claude continue prompt, and the one follow-up after a question stays on that process.
A stream that goes silent is stopped, and the session id from the first line is kept so the next run can resume.
The reviewer agent cannot edit files or run a shell, and the cost on the Claude result line is stored on the job.
A plan command on an Azure work item is kept when the same save also changes state.
Jira comment paging continues while total says more comments remain.
A failed disk write no longer looks saved, a cancelled queue row stays cancelled, and Analytics search treats percent and underscore as literal text.
If the SQLite index write fails, Jobs, schedules, and sessions read the JSON files.
Diagnostic zips redact environment names that contain KEY, including CODEX_API_KEY.
Job transcripts can be read from the legacy .jira-agent folder.
Azure Boards jobs are labeled Azure Boards, a Claude user line is labeled You, and a multiline Claude reply is one transcript row.

Yaver 0.9.58

A failed push used to leave unpushed commits and dirty files in the reused clone, so the next push was rejected.
Yaver now hard-resets that work tree before the next job, fetches the remote branch when it exists, and recreates the branch from the target when it does not.

Yaver 0.9.57

Implement and Revise on a plan-ready job write the same Jira label or Azure work-item comment the poller and webhook already accept, and the next poll does the work.
Revise after Implement removes plan_execute as well as plan_ready, so the next poll revises instead of starting the build.
Only the newest job for a ticket shows Plan ready. Older plan rows say Superseded.
The current plan file is a Plan tab on that job, in the same row as Prompt.
If that revision fails, Revise stays on the latest error plan job. It reopens the ticket to plan_ready and queues another revision from the plan file still on disk.
A missing {params} block no longer says the ticket moved to In Progress when the board stayed on To Do.
Invalid Mode errors list plan, build, and test.
On Windows, a client that disappears during accept no longer closes port 8080. The poller keeps running and the dashboard accepts the next connection.

Yaver 0.9.56

Scheduled and Sessions now use a local SQLite index, the same way Jobs does.
schedules.sqlite and opencode-binds.sqlite are created on first start, including when the JSON files are already there.
The JSON files remain the full record, and the Sessions page lists every live bind.

Looking up an existing issue fills repository, source, target, and mode in the same fields as a new issue.
The prompt box shows the ticket text without the {params} block.
Schedule or Run now writes those fields back to Jira only when you change them.
The source choice is labeled custom branch.

Hovering a dot on the Analytics jobs chart shows the time bucket and the exact count for every series that is turned on.

When a merge request cannot be created, the job log and the Jira comment include the remote status and the server message.
Submodules are updated after the work branch is checked out, so the pins match the branch the job edits.

Yaver 0.9.55

Analytics and the Jobs list read a local SQLite index next to the job files. The index is created on first start, including for a data directory that already has months of job JSON. The visible Jobs page still opens those files, so error text and the session id stay on the list.

Storage is one folder, YAVER_BASE_DIR. The default is %LOCALAPPDATA%\Yaver on Windows and ~/.local/share/yaver on Linux. Data is {base}/yaver and clones are {base}/t. An existing YAVER_DATA_DIR or TEMP_DIR_BASE still wins for that path.

The chart step follows the time range. There is no separate Hour, Day, Week, or Month control. The mark is phosphor green, and the in-app wink is larger.

Yaver 0.9.54

A GitLab review keeps the overview comment on the merge request when an inline finding cannot be posted. That skip is logged, and it no longer fails the whole MR job. Linux install and start scripts are stored with LF line endings, so WSL bash can run them.

Yaver 0.9.53

Analytics splits merge requests Yaver opened from ones it only commented on. Open, Merged, and Closed cards go to a list of the unique MR and PR links. Counts are split into Opened by us (Jira or Azure Boards) and Contributed (a comment on an existing GitLab MR or Azure PR). Review and build jobs on the same URL still count once. Search and Issue key filters are gone from Analytics.

Yaver 0.9.52

Selected code on a GitLab or Azure review comment reaches the agent. An inline /yaver, /review, or /ask on a selected range puts the file, the lines, and a clone snippet in the prompt. A reply on that thread loads the original range and the earlier notes. Azure PR file-thread comments load the file, lines, and parent comments from the thread API, because the webhook does not send them. The Scheduled list pages the same way Jobs does, 25 rows at a time. Analytics shows Open, Merged, Closed, and Total cards for unique merge requests stored on the jobs.

Yaver 0.9.51

A second GitLab /yaver on the same merge request no longer fails to push. The queued follow-up fetches the first job's push and rebases onto it before delivering, so the local branch does not stay behind origin (tip of your current branch is behind).

Yaver 0.9.50

Analytics no longer hangs when the page refreshes or a chart request is slow. A live tick does not abort an Analytics GET that is already running. Changing the period or the filters still cancels the previous request. The daemon stops a cancelled walk and returns 504 if aggregation takes longer than 55 seconds. Issue key is an exact match, so KAN-24 does not include KAN-240. Search still matches a substring, and several keys can be separated by commas. Azure /yaver on a plan_ready ticket posts the same wait note GitLab already posts on the MR. Implement still waits for plan_execute. Plan ready and in flight show up on the cards, the chart, and the tables. Repository URLs with or without .git count as one repo. Jobs with no model appear as (unset) so the shares add up to 100%. There is a By agent table and a repository filter. A custom range copies the current from and to dates instead of jumping to all time. GET /api/analytics runs off the event loop, so Jobs and Stop stay responsive.

Yaver 0.9.49

Analytics no longer times out when you change the chart bucket. Switching the period or the bucket, for example from 24 hours to Month, cancels the previous Analytics GET instead of showing Request timed out. The request budget is 60 seconds. The bucket series is capped so a coarse bucket cannot hang the handler.

Yaver 0.9.48

The dashboard has an Analytics page at /analytics. It charts job counts over time and can filter by status, model, category, source, and more. When a GitLab MR or an Azure PR is merged or closed, Yaver still deletes the clone, the session logs, and the OpenCode rows, and it keeps job_*.json so Analytics can count those runs. Deleting a row from Jobs still removes it. /review and /ask no longer reset a ticket that is waiting at plan_ready. They rebind onto a synthetic GL or AZ key. A failed plan_execute stays retryable. The label is not renamed to plan_executed before implement finishes.

Yaver 0.9.47

On Windows, Storage Delete and merged-review clone cleanup no longer follow the .yaver-plans junction into {YAVER_DATA_DIR}/plans. Deleting one clone no longer deletes plan files that belong to other tickets.

Yaver 0.9.46

When a GitLab MR or an Azure PR is merged or closed, Yaver also deletes that review's jobs, session logs, plan file, issue state, and OpenCode session rows. The shared daemon log is kept, and a job that is still running is skipped. After each OpenCode GET /session/{id}/message, the job session log records the last assistant finish, info.finish, and step-finish.

Yaver 0.9.45

The dashboard uses the new Yaver mark. The sidebar, the login gate, and the boot splash show icon A as a short wink GIF. The README uses lockup C (YAVER / Sanal Geliştirici).

Yaver 0.9.44

Opening a Sessions workspace no longer times out while the clone size is measured. The detail GET uses the Storage size cache instead of walking the temp clone on the request. The SPA aborts GETs after 15 seconds, and walking a real clone on Windows or WSL can take longer than that.

Yaver 0.9.43

A Sessions worksp...

Yaver 0.9.59

Yaver 0.9.59

Claude Code is now a third unattended worker beside OpenCode and Codex.
A plan, build, test, or review job can run claude in print mode with the derman agents, stream the transcript to the dashboard, and resume that same session later.
The dashboard shows Claude jobs in the worker views.
The offline CLI zip installs pinned OpenCode, Codex, and Claude Code, and install-agents copies the derman agents into both homes.
OpenCode, Codex, and Claude each keep their own session for the same repository, branch, target, and kind.
A Claude resume uses the Claude continue prompt, and the one follow-up after a question stays on that process.
A stream that goes silent is stopped, and the session id from the first line is kept so the next run can resume.
The reviewer agent cannot edit files or run a shell, and the cost on the Claude result line is stored on the job.
A plan command on an Azure work item is kept when the same save also changes state.
Jira comment paging continues while total says more comments remain.
A failed disk write no longer looks saved, a cancelled queue row stays cancelled, and Analytics search treats percent and underscore as literal text.
If the SQLite index write fails, Jobs, schedules, and sessions read the JSON files.
Diagnostic zips redact environment names that contain KEY, including CODEX_API_KEY.
Job transcripts can be read from the legacy .jira-agent folder.
Azure Boards jobs are labeled Azure Boards, a Claude user line is labeled You, and a multiline Claude reply is one transcript row.

Yaver 0.9.58

A failed push used to leave unpushed commits and dirty files in the reused clone, so the next push was rejected.
Yaver now hard-resets that work tree before the next job, fetches the remote branch when it exists, and recreates the branch from the target when it does not.

Yaver 0.9.57

Implement and Revise on a plan-ready job write the same Jira label or Azure work-item comment the poller and webhook already accept, and the next poll does the work.
Revise after Implement removes plan_execute as well as plan_ready, so the next poll revises instead of starting the build.
Only the newest job for a ticket shows Plan ready. Older plan rows say Superseded.
The current plan file is a Plan tab on that job, in the same row as Prompt.
If that revision fails, Revise stays on the latest error plan job. It reopens the ticket to plan_ready and queues another revision from the plan file still on disk.
A missing {params} block no longer says the ticket moved to In Progress when the board stayed on To Do.
Invalid Mode errors list plan, build, and test.
On Windows, a client that disappears during accept no longer closes port 8080. The poller keeps running and the dashboard accepts the next connection.

Yaver 0.9.56

Scheduled and Sessions now use a local SQLite index, the same way Jobs does.
schedules.sqlite and opencode-binds.sqlite are created on first start, including when the JSON files are already there.
The JSON files remain the full record, and the Sessions page lists every live bind.

Looking up an existing issue fills repository, source, target, and mode in the same fields as a new issue.
The prompt box shows the ticket text without the {params} block.
Schedule or Run now writes those fields back to Jira only when you change them.
The source choice is labeled custom branch.

Hovering a dot on the Analytics jobs chart shows the time bucket and the exact count for every series that is turned on.

When a merge request cannot be created, the job log and the Jira comment include the remote status and the server message.
Submodules are updated after the work branch is checked out, so the pins match the branch the job edits.

Yaver 0.9.55

Analytics and the Jobs list read a local SQLite index next to the job files. The index is created on first start, including for a data directory that already has months of job JSON. The visible Jobs page still opens those files, so error text and the session id stay on the list.

Storage is one folder, YAVER_BASE_DIR. The default is %LOCALAPPDATA%\Yaver on Windows and ~/.local/share/yaver on Linux. Data is {base}/yaver and clones are {base}/t. An existing YAVER_DATA_DIR or TEMP_DIR_BASE still wins for that path.

The chart step follows the time range. There is no separate Hour, Day, Week, or Month control. The mark is phosphor green, and the in-app wink is larger.

Yaver 0.9.54

A GitLab review keeps the overview comment on the merge request when an inline finding cannot be posted. That skip is logged, and it no longer fails the whole MR job. Linux install and start scripts are stored with LF line endings, so WSL bash can run them.

Yaver 0.9.53

Analytics splits merge requests Yaver opened from ones it only commented on. Open, Merged, and Closed cards go to a list of the unique MR and PR links. Counts are split into Opened by us (Jira or Azure Boards) and Contributed (a comment on an existing GitLab MR or Azure PR). Review and build jobs on the same URL still count once. Search and Issue key filters are gone from Analytics.

Yaver 0.9.52

Selected code on a GitLab or Azure review comment reaches the agent. An inline /yaver, /review, or /ask on a selected range puts the file, the lines, and a clone snippet in the prompt. A reply on that thread loads the original range and the earlier notes. Azure PR file-thread comments load the file, lines, and parent comments from the thread API, because the webhook does not send them. The Scheduled list pages the same way Jobs does, 25 rows at a time. Analytics shows Open, Merged, Closed, and Total cards for unique merge requests stored on the jobs.

Yaver 0.9.51

A second GitLab /yaver on the same merge request no longer fails to push. The queued follow-up fetches the first job's push and rebases onto it before delivering, so the local branch does not stay behind origin (tip of your current branch is behind).

Yaver 0.9.50

Analytics no longer hangs when the page refreshes or a chart request is slow. A live tick does not abort an Analytics GET that is already running. Changing the period or the filters still cancels the previous request. The daemon stops a cancelled walk and returns 504 if aggregation takes longer than 55 seconds. Issue key is an exact match, so KAN-24 does not include KAN-240. Search still matches a substring, and several keys can be separated by commas. Azure /yaver on a plan_ready ticket posts the same wait note GitLab already posts on the MR. Implement still waits for plan_execute. Plan ready and in flight show up on the cards, the chart, and the tables. Repository URLs with or without .git count as one repo. Jobs with no model appear as (unset) so the shares add up to 100%. There is a By agent table and a repository filter. A custom range copies the current from and to dates instead of jumping to all time. GET /api/analytics runs off the event loop, so Jobs and Stop stay responsive.

Yaver 0.9.49

Analytics no longer times out when you change the chart bucket. Switching the period or the bucket, for example from 24 hours to Month, cancels the previous Analytics GET instead of showing Request timed out. The request budget is 60 seconds. The bucket series is capped so a coarse bucket cannot hang the handler.

Yaver 0.9.48

The dashboard has an Analytics page at /analytics. It charts job counts over time and can filter by status, model, category, source, and more. When a GitLab MR or an Azure PR is merged or closed, Yaver still deletes the clone, the session logs, and the OpenCode rows, and it keeps job_*.json so Analytics can count those runs. Deleting a row from Jobs still removes it. /review and /ask no longer reset a ticket that is waiting at plan_ready. They rebind onto a synthetic GL or AZ key. A failed plan_execute stays retryable. The label is not renamed to plan_executed before implement finishes.

Yaver 0.9.47

On Windows, Storage Delete and merged-review clone cleanup no longer follow the .yaver-plans junction into {YAVER_DATA_DIR}/plans. Deleting one clone no longer deletes plan files that belong to other tickets.

Yaver 0.9.46

When a GitLab MR or an Azure PR is merged or closed, Yaver also deletes that review's jobs, session logs, plan file, issue state, and OpenCode session rows. The shared daemon log is kept, and a job that is still running is skipped. After each OpenCode GET /session/{id}/message, the job session log records the last assistant finish, info.finish, and step-finish.

Yaver 0.9.45

The dashboard uses the new Yaver mark. The sidebar, the login gate, and the boot splash show icon A as a short wink GIF. The README uses lockup C (YAVER / Sanal Geliştirici).

Yaver 0.9.44

Opening a Sessions workspace no longer times out while the clone size is measured. The detail GET uses the Storage size cache instead of walking the temp clone on the request. The SPA aborts GETs after 15 seconds, and walking a real clone on Windows or WSL can take longer than that.

Yaver 0.9.43

A Sessions workspace lists every distinct GitLab MR or Azure PR linked from jobs on that repo, source, and target. The Sessions list is paginated at 25 rows per page, and it can be searched by repository, branch, issue key, or kind.

Yaver 0.9.42

Sessions lists one workspace for each repository, source branch, and target branch. The detail page shows the linked OpenCode sessions (plan, build, and test), the jobs, the temp clone with Storage delete when it is not in use, and plan files when a plan bind exists. GitLab and Azure jobs started from the webhook queue take the same per-issue lock as the handle path. Stop plus a leftover /yaver cannot start a second OpenCode session beside the cancelled worker.

Yaver 0.9.41

Windows Distribution no longer fails the GitHub Release when Defender quarantines opencode.exe. The ...

Yaver 0.9.58

Yaver 0.9.58

A failed push used to leave unpushed commits and dirty files in the reused clone, so the next push was rejected.
Yaver now hard-resets that work tree before the next job, fetches the remote branch when it exists, and recreates the branch from the target when it does not.

Yaver 0.9.57

Implement and Revise on a plan-ready job write the same Jira label or Azure work-item comment the poller and webhook already accept, and the next poll does the work.
Revise after Implement removes plan_execute as well as plan_ready, so the next poll revises instead of starting the build.
Only the newest job for a ticket shows Plan ready. Older plan rows say Superseded.
The current plan file is a Plan tab on that job, in the same row as Prompt.
If that revision fails, Revise stays on the latest error plan job. It reopens the ticket to plan_ready and queues another revision from the plan file still on disk.
A missing {params} block no longer says the ticket moved to In Progress when the board stayed on To Do.
Invalid Mode errors list plan, build, and test.
On Windows, a client that disappears during accept no longer closes port 8080. The poller keeps running and the dashboard accepts the next connection.

Yaver 0.9.56

Scheduled and Sessions now use a local SQLite index, the same way Jobs does.
schedules.sqlite and opencode-binds.sqlite are created on first start, including when the JSON files are already there.
The JSON files remain the full record, and the Sessions page lists every live bind.

Looking up an existing issue fills repository, source, target, and mode in the same fields as a new issue.
The prompt box shows the ticket text without the {params} block.
Schedule or Run now writes those fields back to Jira only when you change them.
The source choice is labeled custom branch.

Hovering a dot on the Analytics jobs chart shows the time bucket and the exact count for every series that is turned on.

When a merge request cannot be created, the job log and the Jira comment include the remote status and the server message.
Submodules are updated after the work branch is checked out, so the pins match the branch the job edits.

Yaver 0.9.55

Analytics and the Jobs list read a local SQLite index next to the job files. The index is created on first start, including for a data directory that already has months of job JSON. The visible Jobs page still opens those files, so error text and the session id stay on the list.

Storage is one folder, YAVER_BASE_DIR. The default is %LOCALAPPDATA%\Yaver on Windows and ~/.local/share/yaver on Linux. Data is {base}/yaver and clones are {base}/t. An existing YAVER_DATA_DIR or TEMP_DIR_BASE still wins for that path.

The chart step follows the time range. There is no separate Hour, Day, Week, or Month control. The mark is phosphor green, and the in-app wink is larger.

Yaver 0.9.54

A GitLab review keeps the overview comment on the merge request when an inline finding cannot be posted. That skip is logged, and it no longer fails the whole MR job. Linux install and start scripts are stored with LF line endings, so WSL bash can run them.

Yaver 0.9.53

Analytics splits merge requests Yaver opened from ones it only commented on. Open, Merged, and Closed cards go to a list of the unique MR and PR links. Counts are split into Opened by us (Jira or Azure Boards) and Contributed (a comment on an existing GitLab MR or Azure PR). Review and build jobs on the same URL still count once. Search and Issue key filters are gone from Analytics.

Yaver 0.9.52

Selected code on a GitLab or Azure review comment reaches the agent. An inline /yaver, /review, or /ask on a selected range puts the file, the lines, and a clone snippet in the prompt. A reply on that thread loads the original range and the earlier notes. Azure PR file-thread comments load the file, lines, and parent comments from the thread API, because the webhook does not send them. The Scheduled list pages the same way Jobs does, 25 rows at a time. Analytics shows Open, Merged, Closed, and Total cards for unique merge requests stored on the jobs.

Yaver 0.9.51

A second GitLab /yaver on the same merge request no longer fails to push. The queued follow-up fetches the first job's push and rebases onto it before delivering, so the local branch does not stay behind origin (tip of your current branch is behind).

Yaver 0.9.50

Analytics no longer hangs when the page refreshes or a chart request is slow. A live tick does not abort an Analytics GET that is already running. Changing the period or the filters still cancels the previous request. The daemon stops a cancelled walk and returns 504 if aggregation takes longer than 55 seconds. Issue key is an exact match, so KAN-24 does not include KAN-240. Search still matches a substring, and several keys can be separated by commas. Azure /yaver on a plan_ready ticket posts the same wait note GitLab already posts on the MR. Implement still waits for plan_execute. Plan ready and in flight show up on the cards, the chart, and the tables. Repository URLs with or without .git count as one repo. Jobs with no model appear as (unset) so the shares add up to 100%. There is a By agent table and a repository filter. A custom range copies the current from and to dates instead of jumping to all time. GET /api/analytics runs off the event loop, so Jobs and Stop stay responsive.

Yaver 0.9.49

Analytics no longer times out when you change the chart bucket. Switching the period or the bucket, for example from 24 hours to Month, cancels the previous Analytics GET instead of showing Request timed out. The request budget is 60 seconds. The bucket series is capped so a coarse bucket cannot hang the handler.

Yaver 0.9.48

The dashboard has an Analytics page at /analytics. It charts job counts over time and can filter by status, model, category, source, and more. When a GitLab MR or an Azure PR is merged or closed, Yaver still deletes the clone, the session logs, and the OpenCode rows, and it keeps job_*.json so Analytics can count those runs. Deleting a row from Jobs still removes it. /review and /ask no longer reset a ticket that is waiting at plan_ready. They rebind onto a synthetic GL or AZ key. A failed plan_execute stays retryable. The label is not renamed to plan_executed before implement finishes.

Yaver 0.9.47

On Windows, Storage Delete and merged-review clone cleanup no longer follow the .yaver-plans junction into {YAVER_DATA_DIR}/plans. Deleting one clone no longer deletes plan files that belong to other tickets.

Yaver 0.9.46

When a GitLab MR or an Azure PR is merged or closed, Yaver also deletes that review's jobs, session logs, plan file, issue state, and OpenCode session rows. The shared daemon log is kept, and a job that is still running is skipped. After each OpenCode GET /session/{id}/message, the job session log records the last assistant finish, info.finish, and step-finish.

Yaver 0.9.45

The dashboard uses the new Yaver mark. The sidebar, the login gate, and the boot splash show icon A as a short wink GIF. The README uses lockup C (YAVER / Sanal Geliştirici).

Yaver 0.9.44

Opening a Sessions workspace no longer times out while the clone size is measured. The detail GET uses the Storage size cache instead of walking the temp clone on the request. The SPA aborts GETs after 15 seconds, and walking a real clone on Windows or WSL can take longer than that.

Yaver 0.9.43

A Sessions workspace lists every distinct GitLab MR or Azure PR linked from jobs on that repo, source, and target. The Sessions list is paginated at 25 rows per page, and it can be searched by repository, branch, issue key, or kind.

Yaver 0.9.42

Sessions lists one workspace for each repository, source branch, and target branch. The detail page shows the linked OpenCode sessions (plan, build, and test), the jobs, the temp clone with Storage delete when it is not in use, and plan files when a plan bind exists. GitLab and Azure jobs started from the webhook queue take the same per-issue lock as the handle path. Stop plus a leftover /yaver cannot start a second OpenCode session beside the cancelled worker.

Yaver 0.9.41

Windows Distribution no longer fails the GitHub Release when Defender quarantines opencode.exe. The payload check lists every missing path. If vendor/opencode-home.zip is in the zip, a missing opencode.exe is a warning, not a failed release. The zip is still enough to install.

Yaver 0.9.40

The Windows offline zip is attached to the GitHub Release again. CI turns off runner Defender scanning of opencode.exe and restores the binary from vendor/bin if antivirus removed the copy under opencoderman/vendor/bin/windows. That check had been failing on every Windows zip from 0.9.36 through 0.9.39, so those releases never received the offline zip.

Yaver 0.9.39

A compact recap with finish=None is not a crash and it is not success. OpenCode 1.18 lists the compact recap (agent=compaction, summary=true) before info.finish is set, while the UI already shows the summary. The work turn in the log is finish='stop' with summary=None. That recap means the job is still incomplete, so Yaver waits for auto-resume. Success counts only after a later assistant turn that is not a recap.

Yaver 0.9.38

The Windows offline zip builds again. CI requires opencoderman/agents/derman-reviewer.md, which is the agent actually in the tree, instead of the old code-reviewer.md alias. It also checks the current Settings copy, so the zip is attached to the GitHub Release.

Yaver 0.9.37

Unused temp clones older than 7 days are deleted once an hour. The limit is TEMP_CLONE_MAX_AGE_DAYS in Settings. A job that is still running is never removed. Set the value to 0 to turn the policy off. The OpenCode session bind is kept, so a later mention on the same MR or PR reclones the repo and resumes that session.

Yaver 0.9.36

The dashboard...

Yaver 0.9.57

Yaver 0.9.57

Implement and Revise on a plan-ready job write the same Jira label or Azure work-item comment the poller and webhook already accept, and the next poll does the work.
Revise after Implement removes plan_execute as well as plan_ready, so the next poll revises instead of starting the build.
Only the newest job for a ticket shows Plan ready. Older plan rows say Superseded.
The current plan file is a Plan tab on that job, in the same row as Prompt.
If that revision fails, Revise stays on the latest error plan job. It reopens the ticket to plan_ready and queues another revision from the plan file still on disk.
A missing {params} block no longer says the ticket moved to In Progress when the board stayed on To Do.
Invalid Mode errors list plan, build, and test.
On Windows, a client that disappears during accept no longer closes port 8080. The poller keeps running and the dashboard accepts the next connection.

Yaver 0.9.56

Scheduled and Sessions now use a local SQLite index, the same way Jobs does.
schedules.sqlite and opencode-binds.sqlite are created on first start, including when the JSON files are already there.
The JSON files remain the full record, and the Sessions page lists every live bind.

Looking up an existing issue fills repository, source, target, and mode in the same fields as a new issue.
The prompt box shows the ticket text without the {params} block.
Schedule or Run now writes those fields back to Jira only when you change them.
The source choice is labeled custom branch.

Hovering a dot on the Analytics jobs chart shows the time bucket and the exact count for every series that is turned on.

When a merge request cannot be created, the job log and the Jira comment include the remote status and the server message.
Submodules are updated after the work branch is checked out, so the pins match the branch the job edits.

Yaver 0.9.55

Analytics and the Jobs list read a local SQLite index next to the job files. The index is created on first start, including for a data directory that already has months of job JSON. The visible Jobs page still opens those files, so error text and the session id stay on the list.

Storage is one folder, YAVER_BASE_DIR. The default is %LOCALAPPDATA%\Yaver on Windows and ~/.local/share/yaver on Linux. Data is {base}/yaver and clones are {base}/t. An existing YAVER_DATA_DIR or TEMP_DIR_BASE still wins for that path.

The chart step follows the time range. There is no separate Hour, Day, Week, or Month control. The mark is phosphor green, and the in-app wink is larger.

Yaver 0.9.54

A GitLab review keeps the overview comment on the merge request when an inline finding cannot be posted. That skip is logged, and it no longer fails the whole MR job. Linux install and start scripts are stored with LF line endings, so WSL bash can run them.

Yaver 0.9.53

Analytics splits merge requests Yaver opened from ones it only commented on. Open, Merged, and Closed cards go to a list of the unique MR and PR links. Counts are split into Opened by us (Jira or Azure Boards) and Contributed (a comment on an existing GitLab MR or Azure PR). Review and build jobs on the same URL still count once. Search and Issue key filters are gone from Analytics.

Yaver 0.9.52

Selected code on a GitLab or Azure review comment reaches the agent. An inline /yaver, /review, or /ask on a selected range puts the file, the lines, and a clone snippet in the prompt. A reply on that thread loads the original range and the earlier notes. Azure PR file-thread comments load the file, lines, and parent comments from the thread API, because the webhook does not send them. The Scheduled list pages the same way Jobs does, 25 rows at a time. Analytics shows Open, Merged, Closed, and Total cards for unique merge requests stored on the jobs.

Yaver 0.9.51

A second GitLab /yaver on the same merge request no longer fails to push. The queued follow-up fetches the first job's push and rebases onto it before delivering, so the local branch does not stay behind origin (tip of your current branch is behind).

Yaver 0.9.50

Analytics no longer hangs when the page refreshes or a chart request is slow. A live tick does not abort an Analytics GET that is already running. Changing the period or the filters still cancels the previous request. The daemon stops a cancelled walk and returns 504 if aggregation takes longer than 55 seconds. Issue key is an exact match, so KAN-24 does not include KAN-240. Search still matches a substring, and several keys can be separated by commas. Azure /yaver on a plan_ready ticket posts the same wait note GitLab already posts on the MR. Implement still waits for plan_execute. Plan ready and in flight show up on the cards, the chart, and the tables. Repository URLs with or without .git count as one repo. Jobs with no model appear as (unset) so the shares add up to 100%. There is a By agent table and a repository filter. A custom range copies the current from and to dates instead of jumping to all time. GET /api/analytics runs off the event loop, so Jobs and Stop stay responsive.

Yaver 0.9.49

Analytics no longer times out when you change the chart bucket. Switching the period or the bucket, for example from 24 hours to Month, cancels the previous Analytics GET instead of showing Request timed out. The request budget is 60 seconds. The bucket series is capped so a coarse bucket cannot hang the handler.

Yaver 0.9.48

The dashboard has an Analytics page at /analytics. It charts job counts over time and can filter by status, model, category, source, and more. When a GitLab MR or an Azure PR is merged or closed, Yaver still deletes the clone, the session logs, and the OpenCode rows, and it keeps job_*.json so Analytics can count those runs. Deleting a row from Jobs still removes it. /review and /ask no longer reset a ticket that is waiting at plan_ready. They rebind onto a synthetic GL or AZ key. A failed plan_execute stays retryable. The label is not renamed to plan_executed before implement finishes.

Yaver 0.9.47

On Windows, Storage Delete and merged-review clone cleanup no longer follow the .yaver-plans junction into {YAVER_DATA_DIR}/plans. Deleting one clone no longer deletes plan files that belong to other tickets.

Yaver 0.9.46

When a GitLab MR or an Azure PR is merged or closed, Yaver also deletes that review's jobs, session logs, plan file, issue state, and OpenCode session rows. The shared daemon log is kept, and a job that is still running is skipped. After each OpenCode GET /session/{id}/message, the job session log records the last assistant finish, info.finish, and step-finish.

Yaver 0.9.45

The dashboard uses the new Yaver mark. The sidebar, the login gate, and the boot splash show icon A as a short wink GIF. The README uses lockup C (YAVER / Sanal Geliştirici).

Yaver 0.9.44

Opening a Sessions workspace no longer times out while the clone size is measured. The detail GET uses the Storage size cache instead of walking the temp clone on the request. The SPA aborts GETs after 15 seconds, and walking a real clone on Windows or WSL can take longer than that.

Yaver 0.9.43

A Sessions workspace lists every distinct GitLab MR or Azure PR linked from jobs on that repo, source, and target. The Sessions list is paginated at 25 rows per page, and it can be searched by repository, branch, issue key, or kind.

Yaver 0.9.42

Sessions lists one workspace for each repository, source branch, and target branch. The detail page shows the linked OpenCode sessions (plan, build, and test), the jobs, the temp clone with Storage delete when it is not in use, and plan files when a plan bind exists. GitLab and Azure jobs started from the webhook queue take the same per-issue lock as the handle path. Stop plus a leftover /yaver cannot start a second OpenCode session beside the cancelled worker.

Yaver 0.9.41

Windows Distribution no longer fails the GitHub Release when Defender quarantines opencode.exe. The payload check lists every missing path. If vendor/opencode-home.zip is in the zip, a missing opencode.exe is a warning, not a failed release. The zip is still enough to install.

Yaver 0.9.40

The Windows offline zip is attached to the GitHub Release again. CI turns off runner Defender scanning of opencode.exe and restores the binary from vendor/bin if antivirus removed the copy under opencoderman/vendor/bin/windows. That check had been failing on every Windows zip from 0.9.36 through 0.9.39, so those releases never received the offline zip.

Yaver 0.9.39

A compact recap with finish=None is not a crash and it is not success. OpenCode 1.18 lists the compact recap (agent=compaction, summary=true) before info.finish is set, while the UI already shows the summary. The work turn in the log is finish='stop' with summary=None. That recap means the job is still incomplete, so Yaver waits for auto-resume. Success counts only after a later assistant turn that is not a recap.

Yaver 0.9.38

The Windows offline zip builds again. CI requires opencoderman/agents/derman-reviewer.md, which is the agent actually in the tree, instead of the old code-reviewer.md alias. It also checks the current Settings copy, so the zip is attached to the GitHub Release.

Yaver 0.9.37

Unused temp clones older than 7 days are deleted once an hour. The limit is TEMP_CLONE_MAX_AGE_DAYS in Settings. A job that is still running is never removed. Set the value to 0 to turn the policy off. The OpenCode session bind is kept, so a later mention on the same MR or PR reclones the repo and resumes that session.

Yaver 0.9.36

The dashboard stays up while many clones are running. Git clone, checkout, push, and clone delete use a dedicated yaver-git thread pool sized to the maximum number of concurrent jobs. Those git calls no longer occupy FastAPI's default executor, so /api/jobs and /ws do not hang behind git clone...

Yaver 0.9.56

Yaver 0.9.56

Scheduled and Sessions now use a local SQLite index, the same way Jobs does.
schedules.sqlite and opencode-binds.sqlite are created on first start, including when the JSON files are already there.
The JSON files remain the full record, and the Sessions page lists every live bind.

Looking up an existing issue fills repository, source, target, and mode in the same fields as a new issue.
The prompt box shows the ticket text without the {params} block.
Schedule or Run now writes those fields back to Jira only when you change them.
The source choice is labeled custom branch.

Hovering a dot on the Analytics jobs chart shows the time bucket and the exact count for every series that is turned on.

When a merge request cannot be created, the job log and the Jira comment include the remote status and the server message.
Submodules are updated after the work branch is checked out, so the pins match the branch the job edits.

Yaver 0.9.55

Analytics and the Jobs list read a local SQLite index next to the job files. The index is created on first start, including for a data directory that already has months of job JSON. The visible Jobs page still opens those files, so error text and the session id stay on the list.

Storage is one folder, YAVER_BASE_DIR. The default is %LOCALAPPDATA%\Yaver on Windows and ~/.local/share/yaver on Linux. Data is {base}/yaver and clones are {base}/t. An existing YAVER_DATA_DIR or TEMP_DIR_BASE still wins for that path.

The chart step follows the time range. There is no separate Hour, Day, Week, or Month control. The mark is phosphor green, and the in-app wink is larger.

Yaver 0.9.54

A GitLab review keeps the overview comment on the merge request when an inline finding cannot be posted. That skip is logged, and it no longer fails the whole MR job. Linux install and start scripts are stored with LF line endings, so WSL bash can run them.

Yaver 0.9.53

Analytics splits merge requests Yaver opened from ones it only commented on. Open, Merged, and Closed cards go to a list of the unique MR and PR links. Counts are split into Opened by us (Jira or Azure Boards) and Contributed (a comment on an existing GitLab MR or Azure PR). Review and build jobs on the same URL still count once. Search and Issue key filters are gone from Analytics.

Yaver 0.9.52

Selected code on a GitLab or Azure review comment reaches the agent. An inline /yaver, /review, or /ask on a selected range puts the file, the lines, and a clone snippet in the prompt. A reply on that thread loads the original range and the earlier notes. Azure PR file-thread comments load the file, lines, and parent comments from the thread API, because the webhook does not send them. The Scheduled list pages the same way Jobs does, 25 rows at a time. Analytics shows Open, Merged, Closed, and Total cards for unique merge requests stored on the jobs.

Yaver 0.9.51

A second GitLab /yaver on the same merge request no longer fails to push. The queued follow-up fetches the first job's push and rebases onto it before delivering, so the local branch does not stay behind origin (tip of your current branch is behind).

Yaver 0.9.50

Analytics no longer hangs when the page refreshes or a chart request is slow. A live tick does not abort an Analytics GET that is already running. Changing the period or the filters still cancels the previous request. The daemon stops a cancelled walk and returns 504 if aggregation takes longer than 55 seconds. Issue key is an exact match, so KAN-24 does not include KAN-240. Search still matches a substring, and several keys can be separated by commas. Azure /yaver on a plan_ready ticket posts the same wait note GitLab already posts on the MR. Implement still waits for plan_execute. Plan ready and in flight show up on the cards, the chart, and the tables. Repository URLs with or without .git count as one repo. Jobs with no model appear as (unset) so the shares add up to 100%. There is a By agent table and a repository filter. A custom range copies the current from and to dates instead of jumping to all time. GET /api/analytics runs off the event loop, so Jobs and Stop stay responsive.

Yaver 0.9.49

Analytics no longer times out when you change the chart bucket. Switching the period or the bucket, for example from 24 hours to Month, cancels the previous Analytics GET instead of showing Request timed out. The request budget is 60 seconds. The bucket series is capped so a coarse bucket cannot hang the handler.

Yaver 0.9.48

The dashboard has an Analytics page at /analytics. It charts job counts over time and can filter by status, model, category, source, and more. When a GitLab MR or an Azure PR is merged or closed, Yaver still deletes the clone, the session logs, and the OpenCode rows, and it keeps job_*.json so Analytics can count those runs. Deleting a row from Jobs still removes it. /review and /ask no longer reset a ticket that is waiting at plan_ready. They rebind onto a synthetic GL or AZ key. A failed plan_execute stays retryable. The label is not renamed to plan_executed before implement finishes.

Yaver 0.9.47

On Windows, Storage Delete and merged-review clone cleanup no longer follow the .yaver-plans junction into {YAVER_DATA_DIR}/plans. Deleting one clone no longer deletes plan files that belong to other tickets.

Yaver 0.9.46

When a GitLab MR or an Azure PR is merged or closed, Yaver also deletes that review's jobs, session logs, plan file, issue state, and OpenCode session rows. The shared daemon log is kept, and a job that is still running is skipped. After each OpenCode GET /session/{id}/message, the job session log records the last assistant finish, info.finish, and step-finish.

Yaver 0.9.45

The dashboard uses the new Yaver mark. The sidebar, the login gate, and the boot splash show icon A as a short wink GIF. The README uses lockup C (YAVER / Sanal Geliştirici).

Yaver 0.9.44

Opening a Sessions workspace no longer times out while the clone size is measured. The detail GET uses the Storage size cache instead of walking the temp clone on the request. The SPA aborts GETs after 15 seconds, and walking a real clone on Windows or WSL can take longer than that.

Yaver 0.9.43

A Sessions workspace lists every distinct GitLab MR or Azure PR linked from jobs on that repo, source, and target. The Sessions list is paginated at 25 rows per page, and it can be searched by repository, branch, issue key, or kind.

Yaver 0.9.42

Sessions lists one workspace for each repository, source branch, and target branch. The detail page shows the linked OpenCode sessions (plan, build, and test), the jobs, the temp clone with Storage delete when it is not in use, and plan files when a plan bind exists. GitLab and Azure jobs started from the webhook queue take the same per-issue lock as the handle path. Stop plus a leftover /yaver cannot start a second OpenCode session beside the cancelled worker.

Yaver 0.9.41

Windows Distribution no longer fails the GitHub Release when Defender quarantines opencode.exe. The payload check lists every missing path. If vendor/opencode-home.zip is in the zip, a missing opencode.exe is a warning, not a failed release. The zip is still enough to install.

Yaver 0.9.40

The Windows offline zip is attached to the GitHub Release again. CI turns off runner Defender scanning of opencode.exe and restores the binary from vendor/bin if antivirus removed the copy under opencoderman/vendor/bin/windows. That check had been failing on every Windows zip from 0.9.36 through 0.9.39, so those releases never received the offline zip.

Yaver 0.9.39

A compact recap with finish=None is not a crash and it is not success. OpenCode 1.18 lists the compact recap (agent=compaction, summary=true) before info.finish is set, while the UI already shows the summary. The work turn in the log is finish='stop' with summary=None. That recap means the job is still incomplete, so Yaver waits for auto-resume. Success counts only after a later assistant turn that is not a recap.

Yaver 0.9.38

The Windows offline zip builds again. CI requires opencoderman/agents/derman-reviewer.md, which is the agent actually in the tree, instead of the old code-reviewer.md alias. It also checks the current Settings copy, so the zip is attached to the GitHub Release.

Yaver 0.9.37

Unused temp clones older than 7 days are deleted once an hour. The limit is TEMP_CLONE_MAX_AGE_DAYS in Settings. A job that is still running is never removed. Set the value to 0 to turn the policy off. The OpenCode session bind is kept, so a later mention on the same MR or PR reclones the repo and resumes that session.

Yaver 0.9.36

The dashboard stays up while many clones are running. Git clone, checkout, push, and clone delete use a dedicated yaver-git thread pool sized to the maximum number of concurrent jobs. Those git calls no longer occupy FastAPI's default executor, so /api/jobs and /ws do not hang behind git clone.

Yaver 0.9.35

Asking for review again after a failed review starts a new job. A GitLab or Azure assign that follows an error no longer reuses the failed queue row (review-update-{iid}). install-opencode-agents.bat and install-opencode-agents.sh copy derman-reviewer.md. They previously copied only the build, plan, and test agents.

Yaver 0.9.34

Assign as reviewer matches the PAT user id, the same way aMIR-mini does, not only the trigger-user string. GitLab uses GET /user. Azure uses connectionData and accepts git.pullrequest.reviewers.update. Settings has a separate Review model (DEFAULT_REVIEW_MODEL). Plan, build, test, and /yaver keep using Default model. An empty review model still uses Default model, and a per-issue Model: line still wins. Settings, under Jira, can turn the board poller and Jira comments off with JIRA_ENABLED=false. GitLab and Azure jobs still run.

Yaver 0.9.33

Azure...