carlos / platform Public

Clone
git clone https://amadan.net/carlos/platform

Plain git — no account needed to clone.

Download

Download this file

  1. Important — Publishing worker never starts. claim_workers.go:17 registers StartPlanLimitsPass, but the explicit worker startup list in cmd/console/main.go never invokes it. Configuring a catalog therefore publishes no default records; catalog changes never propagate; failed inline publishes never retry. Start it through RunClaimWorker alongside the other workers, and test the startup wiring.
  1. Important — Orphaned assignments can permanently block other accounts. accountplans.go:126 always selects the first 200 outstanding accounts. If a catalog change orphans those assignments, each publish fails and they occupy every subsequent batch. Later valid accounts never publish. I reproduced this selection behavior with an in-memory SQLite database. Use pagination or a rotating cursor that advances past failures while retaining them for retry.
  1. Minor — An in-flight request can publish after account deletion. apiaccountplan.go:120 relies on the account lookup performed before reading the request body. An operator request can pass that lookup, pause while the owner deletes the account, then resume. SetAccountPlan accepts the tombstoned account, AccountPlan returns its row, and the handler publishes its limits. The SQL behavior reproduced in memory. Make assignment writes conditional on a live account and synchronize publishing with deletion; cover both inline and background publishing races.
  1. Minor — Misspelled sponsored fields silently disappear. accounts_plan.go:130 accepts {"running_thing":40} as an empty override. The command succeeds and publishes the base plan’s lower limit; updating an existing sponsorship can also remove its previous allowance. Direct API requests have the same permissive decoding. Reject unknown fields in sponsored files and assignment requests before changing the row.
  1. Minor — Pack arithmetic can overflow before ceiling enforcement. catalog.go:214 multiplies and adds unchecked integers. An accepted catalog with base storage 1, pack increment 4611686018427387904, quantity 2, and ceiling 100 produces -9223372036854775807; the ceiling does not correct it. Use checked multiplication and addition, rejecting overflow or saturating safely before clamping.

The executor’s rulings are reasonable: additional catalog validation, SQL classification, the absent-record convention, the corrected census test name, the exact put-only host-claim family and probes, and request validation alongside Effective. The copy organization and review rulings introduce no functional objection.

The remaining deliberate checks look sound statically: content changes alter catalog identity without a version bump; partial sponsorship preserves unset fields and schedule minimums; same-catalog CAS retries protect newer revisions; stale publication cannot mark a newer SQL revision published; authenticated non-operators receive the stdlib 404.

Declined to judge

  • Enforcement, box caching, grace periods, checkout, and sponsorship measurement: assigned to later plans.
  • Approved human-facing wording: expressly excluded.
  • Inherited unauthenticated/service-credential responses: existing authentication policy, matching the referenced store-door convention.
  • Concurrent consoles using different catalogs: beyond the specified single-writer model.
  • Catalog identity after programmatic mutation: no production path mutates the loaded catalog.
  • Unsupported nonadditive ceilings: the implementation plan explicitly limits which ceilings apply.
  • Ignored negative sponsored values or unknown memory tiers: no demonstrated harmful effective-limit change.
  • Repeated --pack flags replacing earlier values: conventional map behavior without a contrary requirement.

Go tests could not start because the read-only sandbox prevented creation of Go’s build directory. Darwin/Windows portability was inspected but not compiled. HEAD remains 80672fad599ca72aba577f78d783d8c6107599f1; the working tree is unchanged.

Verdict: not ready. The missing worker startup and batch starvation block the core publishing behavior.