AppTown v1.0.0-rc.13

Flokkit AppTown v1.0.0-rc.13

RC13 is a full polish pass of the web interface: Services now has its own page,
separate from Integrations, status words say what is known and what is not,
lights in the top bar show confirmed problems, and every page has a short
description and help. Packs become a project's only way-of-working choice:
per-project workflow selection is gone and scheduled maintenance is a pack a
project adopts. Status and Attention can now be trusted: readings are taken in
background checks, kept across restarts, aged by what they measure, and counted
one per row shown. It includes all changes since RC12. Several changes are
breaking; read "Breaking changes" before upgrading. Take matching database and
file backups before upgrading, as described in the
upgrade guide.

Breaking changes

Ways of working (packs are the only choice):

• Per-project workflow selection is removed. Migration 200 drops the stored
  workflow ticks; nothing is migrated or kept. Every project can now run every
  core and extra library workflow plus the workflows its adopted packs supply,
  subject to the usual authority and policy checks, so a workflow that was
  unticked is now available. PUT /api/v1/projects/{slug}/lanes is removed
  (404) and so is the project:configure-workflow capability.
  GET /api/v1/projects/{slug}/lanes is read-only and drops selected.
• Scheduled workflows run only from packs that declare them. A workflow runs
  on its schedule only when an adopted pack version lists it under schedules.
  Making a workflow available never schedules it. After upgrading nothing is
  scheduled until a project adopts such a pack version. The stock server-base
  and frontend-only packs no longer carry dependency-uplift; the new
  dependency-updates pack supplies it and declares
  schedules: [dependency-uplift]. Operator step: adopt dependency-updates
  on every project that should keep its monthly dependency updates. New
  projects have it ticked by default and people can untick it.
• System workflows cannot be started by hand. Starting land,
  adopt-integration, retire-integration or another AppTown-run workflow
  through change admission, MCP create_change / start_change_lane or
  POST /changes/{id}/runs is refused (HTTP 422, an MCP tool error), also for
  administrators. Landing goes through the landing request and restart paths.
  apptown adopt uses the integration wiring endpoint; apptown retire uses
  the new POST /api/v1/projects/{slug}/integrations/{capability}/retire, which
  needs an attached integration plus integration configuration and change and
  run permissions, and offers to detach afterwards.
• Pack pull plans and results drop keptReferenced and deprecated; they
  report workflow availability changes instead. The workflow library drops
  usedBy and its usage line. Policy reports leave out withdrawn workflows
  unless an adopted pack still names them.

Models:

• Per-project model overrides are removed. Models are chosen only by slot and
  profile; a project that needs different models gets its own profile.
  Migration 198 deletes every per-project model row. Move any per-project
  mapping you rely on to a profile before upgrading.
  PUT /api/v1/model-slots with project is refused (400) and
  GET /api/v1/model-slots no longer returns overrides. An eval copy takes its
  arm's profile.
• Profiles have four basic choices. They are Main · strong (main-strong),
  Main · fast (main-fast), Second opinion · strong (secondary-strong) and
  Second opinion · fast (secondary-fast).
  GET /api/v1/model-slots marks them with base and lists them first.
  Migration 199 moves every explicit fast cell to the fast main choice, keeping its
  profile, pattern and time; set fast again only as an advanced task override.
  The stock fallbacks change review to secondary-strong and fast to
  the fast main choice where they still hold the stock value. Rows an operator edited
  are left alone. Guidance checks, fleet conformance checks and new eval judges
  ask for secondary-fast directly, so editing the fast task no longer
  changes them. Stock chains resolve to the same models as before; where an
  operator edited the fast fallback and a profile set fast, fast and
  scout now follow the edited row.
• The basic choices are renamed: default is now main-strong and
  primary-fast is now main-fast. Migration 201 renames the stored settings
  and both ends of every fallback row, keeping models, profiles and times. There
  are no aliases: API calls, workflows and configuration that name default or
  primary-fast must use the new names. PUT /api/v1/model-slots refuses the
  old names (400), and a model request naming one fails with an error that lists
  the current names. Stored workflow model requests are not rewritten: before
  upgrading, find any that name the old choices and edit them by hand. Past
  run records keep the names they ran with, so per-row token spend on the
  profile page reads low for Main · strong and Main · fast until new runs add up.
• A profile is read in full before standard. A task that a profile leaves
  unset now follows its fallback chain within that profile first, and only then
  standard's. A profile's basic choice therefore beats a task set only in
  standard: on a profile that sets Main · strong, review and the fast tasks use
  that profile's model rather than standard's task setting. standard itself is
  unchanged.

Status, checks and Attention:

• Status is read from background checks. Inventory, host capacity, AppTown
  and worker disks, backup protection, integrations, targets, previews and
  deployment details are checked at start and every five minutes. Opening a
  page no longer contacts hosts or providers. The Infrastructure Refresh action
  is removed and GET /api/v1/infrastructure?refresh=1 has no effect. Inventory
  responses replace refreshing with invalidated (the reading predates
  AppTown's latest act at that target). Preview start, restart and stop, and
  deployment actions, repairs and backups, queue a check of what they touched.
• Readings survive restarts and age by what they measure (migrations 194 to
  196). Machine totals stay valid for seven days. Live readings are fresh for 15
  minutes, then "last seen" with their age, and unknown after six hours. A
  failed check keeps the last good values and their time. A pending first check
  raises no Attention item.
• Attention counts one per row it shows, with the same "<n> to fix ·
  <m> not known" wording in its header and on Home. Only integrations with an
  automatic check and a failed latest result count. Package registries,
  scanners that run inside the app image and other kinds with no automatic check
  read "no automatic check". A Test connection result is kept as the last
  state and marked old after 15 minutes. Background target checks need two
  failures in a row to mark a target unreachable.
• A check that could not give an answer is "not known", not a problem. A
  check that could not start, a failed model call or a missing model answer is
  recorded as an evaluation error and shown as not known with its reason.
  Routine deferrals (no standing deployment, no cached image, no evaluator) stay
  not yet assessed and raise nothing. With no model available, AI rubric checks
  read not known. Required checks that cannot answer still stop the gate.
• Display words change. A ready deployment target reads working (was
  passed). Integration health adds not set up; GitLab with both settings
  empty is not set up, not failed, and a partly configured GitLab or Infisical
  is failed and names the missing setting. Disk warnings apply below 10% free on
  every disk; the former 40 GiB cap is gone. Attention item titles now name
  their host or app; do not match the old wording.
• Manual scanners may declare appliesTo. A tool check runs only where both
  the check and its scanner apply. The stock hadolint scanner declares build,
  so it no longer runs, or reports a missing Dockerfile, on static-only apps.
• Container registry checks sign in. Listings, saves and Test connection
  call GET /v2/ over HTTPS with the configured username and token, following a
  Bearer challenge only to a token service on the same domain. A registry that
  refuses the credentials now reads failed.

Projects, Home and pages:

• Project descriptions are generated. blurb on project creation (HTTP,
  MCP create_project, apptown new) is now the original request, kept in
  the project's history. AppTown writes a short description from it in the
  background with the fast model; with no model it stays empty. Migration 193
  keeps every existing description as written by a person, so it is not
  regenerated until someone clears it. Project responses add blurbSource and,
  on detail, originalRequest.
• GET /api/v1/projects?order=recent is removed (400). Use order=running
  or order=mine with limit and offset.
• The workflow catalogue moves from /workflow-library to /workflows,
  with no redirect. Update bookmarks.

Containers:

• Docker labels for people move to apptown.info.*. Containers, networks
  and volumes carry apptown.info.project and apptown.info.deployment;
  change previews carry apptown.info.project and apptown.info.change (the
  change title, cut at 120 bytes). apptown.deployment.name is no longer
  written, and the wrongly written <project>=<project> label is gone.
  Existing resources keep their old labels until they are recreated. AppTown
  reads none of these labels, so ownership and cleanup are unchanged; update any
  docker ps filters or display commands you use.

New and improved

• Services and Integrations are separate. Integrations holds a project's
  connections; Services holds what AppTown itself offers (shared services, error
  reporting, model profiles). Model profiles are a list, each building on
  standard.
• One look across AppTown. A compact layout in light and dark, one status
  component with plain state words and a grey dot for neutral states, a one-line
  description and help bubble on every page, and glossary entries for the new
  terms. Pages lead with names and state; technical detail is a tap away.
• Attention lights in the top bar, one per kind of confirmed problem, shown
  to operators. A failed Attention read shows an unknown light.
• Home is the place to open apps. It leads with running apps and an Open app
  action at every width, shows each person's recent projects first, and keeps
  your own open changes visible between runs with a plain state ("ready to land",
  "being edited in a chat", "No workflow is running").
• A project's Way of working page shows its packs and, read only, what they
  give it: guidance, rules, checks and workflows.
• Clearer pages. Departures are grouped by day; the change page opens on
  Work, aligns its steps, puts the approve form beside the failed check and shows
  approvers the summary or the agent's report. People has tabs for accounts,
  groups and roles, sign-in, and coding agents and tokens. Phone navigation
  keeps tabs in one scrollable row. Usage says "under 1s" for sub-second steps.
• Built-in app addresses work when AppTown's public host has a port. An app
  or preview address replaces AppTown's port with the app's published port, so
  localhost:7777 installs can deploy.
• Change previews are counted correctly in inventory, from the resources
  their boot recorded, so a preview with postgres no longer shows a missing and
  an unrecorded container.
• Stale sign-in cookies are cleared, so a browser with an ended session is
  simply signed out. Backup check failures in Attention say what went wrong and
  what to do.
• Native installs set HOME. The shipped systemd unit sets HOME=/root, so
  attaching a Docker host can write its SSH configuration. Copy the new
  deploy/systemd/apptownd.service or add the line to your unit.
• Setup guidance. A new setups guide compares installs, workers and
  deployment targets and recommends private (tailnet) access to AppTown and
  previews, with public ingress only for production apps.
• Jobs queued while AppTown starts are no longer lost to a start-up race.
• Release process. CI runs once per landing, in the merge queue; the full
  heavy test run happens on every main commit after merge and a heavy failure
  blocks the next release candidate. Renovate now covers every pinned version.
  The frozen RC12 upgrade fixture is included.

Declaration changes

Pack declarations add schedules (workflows the pack runs on their schedule)
and suggested (preselected for new projects); see Breaking changes. Manual
scanner declarations may add appliesTo. No other application-contract,
workflow, check or pack declaration fields are added or removed.

HTTP API changes

These changes are relative to RC12. The HTTP API remains experimental. The
OpenAPI description
contains the available route definitions.

• Removed: PUT /api/v1/projects/{slug}/lanes. GET .../lanes drops
  selected.
• Added: POST /api/v1/integrations/{name}/test (Test connection on a saved
  integration) and POST /api/v1/projects/{slug}/integrations/{capability}/retire.
• POST /changes/{id}/runs and change admission refuse system workflows (422).
• GET /api/v1/model-slots drops overrides and adds base on each slot, and
  returns the basic choices as main-strong, main-fast, secondary-strong
  and secondary-fast; PUT /api/v1/model-slots refuses project and the
  retired names default and primary-fast.
• GET /api/v1/projects refuses order=recent and accepts order=running and
  order=mine; project rows add lastWorkedAt, lastChangeTitle,
  productionUrl, hasDeployments, canChange, blurbSource, targetName
  and unreachableSince; project detail adds originalRequest and
  chatAvailable.
• GET /api/v1/infrastructure ignores refresh=1 and replaces refreshing
  with invalidated; capacity, filesystem, tenant and native backup readings
  add reading and failure times, stale and unknown.
• Integration health adds automatic, lastResult, lastGood, failedAt,
  failure, expired and stale, and the not set up state; target readings
  add consecutiveFailures; a ready target's statusLabel is working.
• Attention items add unknown, attemptedAt, count and statusLabel;
  coverage adds attemptedAt, reason, nextStep and href.
• GET /api/v1/activity adds open and openTotal (the reader's own open
  changes, each with a state and, when idle, idleSince).
• Conformance observations add lane; project standing adds notKnown;
  conformance summaries add incompleteProjects.
• Pack responses add schedules and suggested; pack pull plans and results
  drop keptReferenced and deprecated; the workflow library drops usedBy.
• Display labels are added from the server: statusLabel on runs, steps,
  backups, releases, decisions, ADRs, managed needs, operations and review
  summaries; readinessLabel and restoreLabel on deployments; mergeLabel
  on change evidence; outcomeLabels on what-if summaries.
• Releases add failure; departures add reason and releaseNumber; release
  contents add each change's number; guidance listings add summary;
  /auth/me may add ownTokens.

Deprecations

None.