v0.2.0-alpha.6

BuildMax is an out-of-the-box, privately deployable Agent platform: a CLI/TUI,
a desktop app, and a team Portal on one shared Go Agent Runtime.

0.2.0-alpha.5 carries the same changes but published nothing: it was tagged,
and its release build then failed before uploading any archive or image. Only
its Portal image exists. This version replaces it.

Highlights

• The agent now remembers a local project between sessions. Each project keeps
  small Markdown memories under a generated index; only the index is carried
  into a turn, and the agent opens a memory when the line suggests it is worth
  reading. Every surface can see what a project remembers: buildmax info, the
  TUI /info panel, and a read-only Memory view in Desktop.
• Team issues reach the terminal. buildmax issue list, issue show, and
  issue status work the issues a team assigned you, and buildmax --issue <id> scopes a local session to one: the agent reads the issue and reports
  back, while status, assignee, and sub-issues stay a person's decision.
• Desktop and the CLI share one local project catalog, so both list the same
  sessions for the same repository, worktrees included.
• /compact compacts a TUI session on demand instead of waiting for the
  context window to fill.
• Alpha releases prepare themselves: a daily check opens a reviewable pull
  request, and merging it is what creates the tag.

Upgrade notes

• A deployment running workers as Kubernetes Jobs must set all four
  worker.k8s.resources bounds. The server now refuses to start when one is
  missing or invalid, naming the key to edit, instead of logging the problem
  and running worker pods unbounded.
• buildmax stats is now buildmax info, and the TUI /stats panel is
  /info. Scripts reading --json get the statistics under stats and the
  new memory listing under project_memory.
• A run trace's prompt_layers record is now context_sources. Anything
  reading traces has to follow the rename; the record now names every source a
  run started with, not only the system-prompt layers.
• --continue is now scoped to the directory you are in, not the newest
  session anywhere on the machine. --continue --project widens it to every
  directory of the project and prints where it will run.

Install

Download the archive for your platform below. Each one contains all three
binaries — buildmax, buildmax-server, buildmax-worker — plus
config-examples/, LICENSE, and NOTICE-THIRD-PARTY. Verify it against
checksums.txt first.

With a Go toolchain, for the CLI alone:

go install github.com/gougoujiang/buildmax/cmd/buildmax@v0.2.0-alpha.6

As a container, for linux/amd64 and linux/arm64:

docker pull ghcr.io/gougoujiang/buildmax:0.2.0-alpha.6

Copy config-examples/settings.example.yaml to ~/.buildmax/settings.yaml,
configure at least one model, then run buildmax for the TUI or
buildmax -p "your prompt" for a single non-interactive turn. Running the
server and Portal additionally needs MySQL and object storage; see the README.

The desktop app is not published here. It needs code signing and notarization
to launch on macOS, so build it locally with ./make build.

Before you deploy this

This is an alpha, and two defaults deserve to be read as warnings rather than
footnotes:

• Server authentication is bootstrap-level. There is no mail channel, so an
  operator creates accounts and issues single-use login codes with
  buildmax-server user create and user login-code. Self-registration is
  closed by default. There is no password, second factor, SSO, or recovery
  flow; putting the Portal on a network you do not control requires wiring a
  real identity provider first.
• The bash sandbox is off by default, and worker hardening is incomplete.

SECURITY.md lists both, along with how to report a vulnerability privately.
Interfaces and deployment guidance may change before a stable release.

Added

• The agent can now remember things about a local project between sessions. A
  project keeps one bounded memory store at
  <BUILDMAX_HOME>/projects/<project_id>/memory/: small Markdown files, one
  per memory, under a generated MEMORY.md index. Only the index is shown to
  the model on every turn, as fallible recall rather than as instruction --
  AGENTS.md stays the place for rules -- and the agent opens a memory's body
  with MemoryRead when the line suggests it is worth reading. MemoryWrite
  creates, replaces, or deletes one memory at a time, and changing a memory
  requires having read it, so two sessions recording different facts never
  collide and a stale write risks one memory instead of the store. Subagents
  receive neither the index nor the tools. The store is shared by every session
  of that project, including those in other worktrees of the same repository,
  it is yours to read, edit, or empty at any time, and --no-project-memory
  runs without it in either direction.

• buildmax --issue <id> scopes a local session to a team issue: the agent can
  read the issue, its sub-issues, and recent discussion, and post a short report
  back. It cannot change the issue's status, assignee, or sub-issues. A report
  from your machine is recorded as a local agent report attributed to you, and
  Portal shows it as reported rather than said — it is not a run the deployment
  scheduled, counted, or traced.

• buildmax issue list shows the issues a team assigned you, across every team
  you belong to, so team work can be picked up from the terminal instead of a
  board in a browser. Listing issues by assignee and by status now works over
  the API too; both filters were described but not implemented.

• buildmax issue show <id> prints one issue with its sub-issues and recent
  discussion, and buildmax issue status <id> <status> moves it when you are
  done. Moving status stays a person's action: an agent working the issue can
  say it believes the work is finished, and you decide. A session started with
  --issue now also prints which server, team, and issue it is working and
  where prompts go, before the first model call.

• An agent working a team issue can now read it and report back. GetIssue
  returns the issue, its sub-issues, and recent discussion; ReportToIssue
  posts one bounded comment on the thread. Both are scoped to the issue the run
  was started for, and neither can change its status, assignee, or sub-issues.

• /compact in the TUI summarizes the conversation so far and continues from
  the summary, instead of waiting for the context window to fill up. It keeps a
  much shorter tail verbatim than the automatic pass, reports what it replaced
  and what the context costs now, and honors the same pre_compact and
  post_compact hooks.

• Desktop has a Memory button beside the message box: it lists what the
  project remembers and shows the body of whichever memory you select, over the
  same store the CLI and TUI read. It is read-only for now — memories are
  Markdown files and the drawer prints the directory so you can edit them
  directly — and it names any file that could not be parsed, since such a memory
  is silently absent from every run until it is repaired.

• buildmax project list shows the local projects and marks the ones whose
  locator no longer resolves; buildmax project relink <project-id> points one
  at the current directory after a repository or folder has moved, keeping the
  memories and sessions attached to it. A run that registers a new project while
  others are unresolved now says so and names the command, since otherwise the
  duplicate looks like the feature working.

• A daily release check now prepares a reviewable pull request once the latest
  alpha is at least 72 hours old and user-visible changes are waiting. Merging
  that pull request creates the version tag and starts the existing publication
  workflows; an empty or unreviewed release is never published on the timer.

• Add ./make ocean to provision disposable DigitalOcean infrastructure, deploy a pinned private application trial, inspect it, and tear it down for beta qualification.

• Add idempotent OpenRouter model initialization for the DigitalOcean trial,
  including automatic selection and rollout of the Tier 1 conversation model.

• Add ./make ocean show all to inspect the standard Kubernetes workload
  resources in the BuildMax namespace with the qualification cluster's isolated
  kubeconfig.

• Add an owner-only Kubernetes tunnel for inspecting the qualification MySQL
  database locally without opening its firewall to the public internet.

Changed

• A deployment running workers as Kubernetes Jobs must now set all four
  worker.k8s.resources bounds, and the server refuses to start when one is
  missing, is not a Kubernetes quantity, is zero or negative, or names a limit
  below its own request. The error names the key to edit. Previously a typo such
  as memory_limit: 4 gigabytes was logged and dropped, which left worker pods
  running model-chosen commands with no memory limit while the configuration
  looked correct.

• --continue now resumes the newest session recorded in the directory you are
  in, rather than the newest session anywhere on the machine. In a repository
  with worktrees, a project-wide search could pick a session from a sibling
  worktree and run there, moving your working root out from under the workflow
  whose whole purpose is branch isolation. When this directory has no sessions
  but the project does, --continue says how many and names --continue --project, which widens the search and prints the directory it will run in.
  The TUI /sessions picker spans the project -- one Git repository including
  all its worktrees, or one plain folder -- and marks sessions recorded in
  another tree; press a to see every project. --resume <id> still finds a
  session by id, but returns to the directory it ran in and refuses to continue
  one that belongs to a different project. buildmax info with no argument
  follows the same scope.

• buildmax stats is now buildmax info, and the TUI /stats panel is
  /info, because both now answer a second question: what the session's project
  remembers. In the TUI the two halves are tabs — tab and the arrow keys
  switch, and on the memory tab enter opens a memory to read the reason behind
  it, which until now meant finding the file by hand. On the command line the
  memory listing follows the statistics, and --json carries both under stats
  and project_memory.

• Desktop and the CLI now share one local project catalog, so both opened on the
  same repository list the same sessions. A folder Desktop already knows --
  including a worktree of a repository in the list -- opens that project instead
  of adding a duplicate, session grouping follows the project a session belongs
  to rather than matching folder paths, and deleting a project no longer takes
  its sessions with it unless you confirm that as well.

• The run trace's prompt_layers record is now context_sources, which names
  every source a run started with rather than only the system-prompt layers: the
  instruction layers and their sizes, the project and the project memory it
  loaded with that document's revision and digest, the session notes and todos
  it inherited, and whether a compaction summary stood in for messages. It
  carries sizes and revisions, never content. buildmax doctor now also reports
  which project the current directory belongs to, where its memory file is and
  whether it fits its budget, and any sessions naming a project this machine no
  longer has.

• Let operators explicitly print qualification database credentials with
  ./make ocean info --show-secrets while keeping ordinary output redacted.

Fixed

• The release build no longer fails after the tag exists. The image scan that
  now runs before publication kept its database inside the checkout, and
  GoReleaser refuses to publish from a worktree git reports as dirty, so
  v0.2.0-alpha.5 was tagged and then published nothing. The scanner now caches
  outside the checkout.

• Editing an issue no longer silently overwrites someone else's change. An
  update now carries the version it was built from, and the server refuses a
  write built on a stale copy; Portal reloads the issue and asks you to reapply.

---

Earlier releases are in
CHANGELOG.md.