BoundedCode v0.1.0-alpha.4

BoundedCode v0.1.0-alpha.4

Do the repositories still work together?

A multi-repository task can pass every repository's own checks and still
break the contract between them. For example, a provider renames a protobuf
field and updates its server, while a client in another repository still
builds against its vendored copy of the generated code. This alpha adds a
cross-repository compatibility gate (experimental). For every gRPC,
protobuf or OpenAPI link that a task's change affects, it reports
compatible, broken or untested, and it records the evidence: the
commands run, their outcomes, and the repositories and commits involved.

Everything else is as in v0.1.0-alpha.3. The local
default, Qwen3.6-35B-A3B on Linux with an NVIDIA GPU, is still the only
validated configuration. The gate is covered by unit, integration and CLI
tests on fixtures, and was run with the real Docker sandbox. It has not
yet been run on real tasks.

Highlights

• Only real changes count. The gate compares the change's base and head
  commits:

  • .proto messages, fields, enums and RPC signatures are compared
    structurally, and breaking changes are recognized: a field removed,
    renumbered, retyped or renamed, or an RPC signature changed.
  • OpenAPI operations are compared together with the schemas they
    reference.
  • Go code is compared by the function that holds the call.
  • Comments, other RPCs and unrelated functions do not count.

• Checked with the repositories' own tests, against each other's new
  commits:

  • gRPC and protobuf (Go): the dependent repository's go test stage
    runs in the sandbox, built against the provider's candidate commit
    through a generated Go workspace. A vendored copy or a replace
    directive does not apply, and coverage must show the dependent's code
    ran.
  • OpenAPI: the dependent's tests must fail when the operation is
    removed from the spec, which shows they actually read it.
  • Failures: control runs at the base commits decide whether a failure
    comes from the change or was already there.

• In the task loop:

  • A broken link fails the attempt, and the agent is told which link
    broke and why.
  • An untested link withholds TASK_VERIFIED. When a test could settle
    it, the agent is asked once for one.
  • Results survive a crash or task resume. A new commit marks them stale.

• Where to see it: task status, verify --full (also --json) and the
  Verification tab of the interface show the per-link report:

  cross-repository compatibility: BROKEN (3 broken, 2 untested, 0 compatible)
    BROKEN     grpc_def     grpc shop.payments.v1.PaymentService/Charge [changed]
               checkout@a5f2bdbb99 internal/pay/client.go:23 -> protos@f70b3b206e payments/v1/payments.proto:9
               checkout's checks fail with protos's candidate (checkout@a5f2bdbb99 + protos@f70b3b206e) and pass with protos's base commit: internal/pay/client.go:23:77: unknown field AmountCents in struct literal of type paymentsv1.ChargeRequest
  

  This example is the new
  contract-break fixture:
  a field rename that all three repositories' own tests pass. See the
  design and its limits.

• Vendored Go modules verify offline. Verification no longer forces
  -mod=mod on a module with vendor/modules.txt. That flag made Go ignore
  the vendored copy and try to download it. A vendored module now builds
  from its tracked vendor/.

Documentation

The README and docs at this tag were written before two clarifications
that are now on main:

• In a multi-repository task, TASK_VERIFIED also requires every affected
  gRPC, protobuf or OpenAPI link to be compatible. See
  Verification and
  the "How it works" diagram, which now shows the gate.
• The sandbox controls
  have an entry for the gate and describe vendored Go modules, and
  CONTRIBUTING.md lists internal/compat as security-sensitive.

The released binaries are unchanged; only the documentation was updated.

Upgrade notes

• The database migrates itself (migration 6).
• Behaviour change: a multi-repository task whose change affects a
  gRPC, protobuf or OpenAPI link now ends task_verified only if every
  such link is shown compatible. Otherwise it ends tests_green, with the
  reason recorded as a decision. To keep the previous behaviour, set
  repointel.compat_gate: false.
• No new dependencies, and the sandbox image is unchanged.

Known limitations

1. The gate checks gRPC and protobuf sides written in Go only: one module
   at the repository root, a go test stage, and generated code committed
   in a task repository (the gate never runs protoc). OpenAPI sides are
   checked only when a test reads the spec. Every other case is reported
   untested, with the reason.
2. compatible for a client and server means that both compile against the
   same new definition and their own tests execute their side. The client
   is never run against the real server.
3. A wire-incompatible definition change stays untested even when every
   task repository agrees. Services already deployed are not tested.
4. Test code is written by the agent and runs inside the check, the same
   trust boundary as for verification. Likewise, the agent can edit a
   vendored module's vendor/ like any other source; only review catches
   that.
5. The limitations of v0.1.0-alpha.3
   still apply.

Please report what you find:
issues. A link reported
broken that was fine, or compatible when it was not, is especially
useful.

Assets

• boundedcode-linux-amd64, boundedcode-linux-arm64,
  boundedcode-darwin-amd64, boundedcode-darwin-arm64,
  boundedcode-windows-amd64.exe, boundedcode-windows-arm64.exe: static
  binaries (CGO disabled).
• SHA256SUMS: checksums, verified by the installers.
• SBOM-<os>-<arch>.spdx.json: SPDX 2.3 software bill of materials of each
  binary.
• boundedcode-v0.1.0-alpha.4-licenses.tar.gz: LICENSE, NOTICE,
  THIRD_PARTY_NOTICES.md and the license texts of every Go module compiled
  into the binaries (LICENSES/go) and of the upstream components
  (LICENSES/upstream).

Model weights are not distributed. Download them with bcode setup or
bcode model fetch, from their publisher at a pinned revision, and review
their license.