1.49.1: the app's one address keeps no cookies, parts started again in their place, and clearer verification

Author: huynvic

CHANGELOG.md

@@ -3,6 +3,27 @@
 Release notes for AlbertCode SWE Agent, newest first. Each release's installers and checksums are
 on the [releases page](https://github.com/huynvic/albertcode-swe-agent/releases).
 
+## 1.49.1 — 2026-10-09
+
+- **Security fix.** The one address **Start all** gives your app (`localhost:4400`) kept cookies, so a
+  second browser could be signed in as the first person. It now keeps none: each browser keeps its
+  own. Affects 1.47.0 to 1.49.0.
+- **Started again in its place.** A part that is up but not working, whose services moved, or whose
+  code changed and does not reload by itself (a worker, say), is started again where it runs, never as
+  a second copy.
+- **Every declared package checked** before a Python part starts, each missing one listed under
+  **Install packages**.
+- **Redis with nothing to connect.** In Development, with `redis-server` installed, AlbertCode runs its
+  own Redis and its answer proves the step.
+- **A service that does not answer is yours to start.** Verification names it and what it said, and
+  asks you to start it or change its connection; nothing is sent to Albert to repair. A browser the
+  tests could not start is something to install.
+- **Clearer evidence.** Each connected service is named with what it answered.
+- **The map reads more of your code:** routes under a router's prefix, endpoints under a parameter,
+  services in variables, packages and setup files, and sign-in token libraries. A line to a later step
+  no longer holds back what is verified before it.
+- **Names on lines never overlap,** and the line between two neighbours keeps its own name.
+
 ## 1.49.0 — 2026-10-08
 
 - **Step by step, the app first.** The System page's **Build** stage starts with **The app runs**: each

docs/architecture.md

@@ -37,6 +37,20 @@ connection:
 Lines need evidence too: the front end calls the API where its code fetches from it; the back end uses
 a database, a sign-in library or a service where the same manifest declares both.
 
+A route on a FastAPI router or a Flask blueprint carries the router's prefix, so the list a router
+serves at `""` is found where it is:
+
+```python
+router = APIRouter(prefix="/api/shipments")
+
+@router.get("")           # GET /api/shipments
+@router.get("/{ref}")     # GET /api/shipments/{ref}
+```
+
+A library that signs and checks tokens (PyJWT, jose, jsonwebtoken) is how the code reaches the sign-in
+provider it also has, such as Okta, and is shown inside that box. Without a provider it is the app's
+own sign-in, a box of its own.
+
 A framework it does not recognise is listed as *found in a manifest*, not guessed at.
 
 ## Only the folder as it is now

docs/security.md

@@ -141,6 +141,9 @@ computer as you, outside the limits AlbertCode puts on the agent's commands:
 - The keys of services you connected are read from your key store when a part starts, given only to
   the parts that use that service, and masked in everything the parts print.
 - Every part, and the app's one address, listens on `127.0.0.1` only.
+- The app's one address keeps no cookies of its own: each browser's cookies go with its own requests,
+  and a cookie a part sets (a session, say) goes back only to the browser that asked, so two people
+  using the app at once are never signed in as each other.
 - What the parts print is kept in memory, masked, and never written into your repository.
 - **Stop all** stops every part and everything it started. Parts left running by an AlbertCode that
   ended without stopping them are stopped the next time it starts, but only when they are verifiably the

docs/system.md

@@ -74,14 +74,33 @@ payments, email and the rest appear on their own, read from the same files the
 | A chip with a port | It is running now (see [Run every part](#run-every-part)) |
 | A tick or a cross | Albert finished, or hit a problem, on this part in the current chat |
 
+**How your code shows a part.** A dashed box turns solid when your code has what it describes: a
+package that reaches it (`@okta/okta-react`, `stripe`), the variable it is configured by, named in a
+`.env.example` (names written for the browser, such as `NEXT_PUBLIC_…` or `VITE_…`, count too), the
+image it runs from in `docker-compose.yml`, or the file that sets it up (`.github/workflows/ci.yml`
+for GitHub Actions, `vercel.json` for Vercel, a `Dockerfile` for Docker). Each build request names
+the variable or file to use, so a box Albert builds turns solid. An API that only sends jobs to a
+Celery worker stays the API: the worker is the folder whose code defines the tasks.
+
+For example, with this `api/.env.example` the Company sign-in (Okta), Error reports (Sentry) and
+Monitoring (Datadog) boxes turn solid:
+
+```text
+OKTA_ISSUER=https://your-company.okta.com/oauth2/default
+SENTRY_DSN=
+DD_API_KEY=
+```
+
 **Moving around.** Drag a box to arrange the map; it stays where you put it, for this repository on
 this computer. Drag empty space to move. <kbd>Ctrl</kbd>/<kbd>⌘</kbd> with the mouse wheel, or **−**
 and **+**, zooms. **Fit** shows everything; **Tidy** lines the boxes up in their lanes. **List** shows
 every part and how it stands; **Library** opens the library.
 
 **Connecting boxes.** Drag a box's dot onto another box, or click the dot and then the other box.
 Select a line to see the file that shows the connection, its [contract](#contracts-on-connections),
-**Go to** either end, or **Remove this connection**.
+**Go to** either end, or **Remove this connection**. Each line is named by what it carries, such as
+*HTTP*, *SQL* or *Sign-in*, where the name covers no box and no other name; when a busy corner leaves
+no room for it, point at the line or select it to read its name.
 
 **Read again** reads the repository afresh, for example after you changed files outside AlbertCode.
 
@@ -322,7 +341,7 @@ one starts:
 | Kind | What it is |
 |---|---|
 | **The app** | The app itself, running: each part answers, and the front end reaches the API. Nothing else yet |
-| **Service** | One service the app uses (a database, sign-in…), added through its adapter. A database must answer AlbertCode's check; an outside service answers through its stand-in |
+| **Service** | One service the app uses (a database, sign-in…), added through its adapter. A database must answer AlbertCode's check; a Redis the runtime runs itself in Development is proven by its answer, with nothing to connect; an outside service answers through its stand-in |
 | **First feature** | The smallest real flow the product has, on the app and its services |
 | **Feature** | Each other feature, in order |
 | **Outside service** | Each outside service (payments, email…) made real: until then the app uses a stand-in |
@@ -347,8 +366,9 @@ its health route and the environment variables it is configured by (names only).
 - **The app**: each part's skeleton in the framework's own layout, starting and answering its health
   route, with a test for it, and the front end reaching the API. *Nothing else yet.*
 - **A service**: that one service added to the part that uses it, through an adapter configured by its
-  environment variables, with a stand-in for tests. A database also gets its migration set up, with no
-  tables until a feature needs one. *No feature uses it yet.*
+  environment variables, with a stand-in for tests. A database with tables (PostgreSQL, MySQL, SQLite
+  and the like) also gets its migration set up, with no tables until a feature needs one; a cache or a
+  queue such as Redis has none to set up. *No feature uses it yet.*
 - **A feature**: the requirement, the journey, how to tell it works, its endpoints and the data it
   keeps (with a migration), built on the parts already in place, and a browser test titled `[R1] …`
   that walks the journey.
@@ -465,10 +485,18 @@ repairs it (*repair 1 of 3*), you accept the fix, and it passes: **Build queue 
    runner, or a browser to run the tests in. The verification stops here, before starting anything, and
    lists each one with what installs it (`npm install` in `web/`, for example) and an **Install** button.
    Installing fetches from the network and runs what it fetches, so it is always your click. This is not
-   a failure of the code: press **Install** on each, then **Verify again**.
-3. **Start the app**: every part the slice needs, through the [runtime](#run-every-part).
+   a failure of the code: press **Install** on each, then **Verify again**. A browser the tests could
+   not start is found here too, even after the app has started: Playwright's own was never downloaded,
+   and the tests do not use the Chrome, Edge or Chromium AlbertCode found on the computer (it names it in
+   `PW_CHROMIUM_PATH`, which each slice's request asks the tests to use).
+3. **Start the app**: every part the slice needs, through the [runtime](#run-every-part). A service
+   connected on the map that does not answer where it is (a database that is down, say) stops it here:
+   the slice asks you to start it or change its connection, and is never sent to Albert to repair.
 4. **Each part answers its health route**.
-5. **Check each connected service**.
+5. **Check each connected service**, each named with what it answered (*Database: Signed in · 4
+   tables · read-only query answered*), and each one the runtime runs itself: in Development, with
+   `redis-server` installed and no Redis connected on the map, the runtime's own Redis answering is
+   the check (*Cache and job queue, run here: PING answered*), and there is nothing to connect.
 6. **Walk every journey in a browser**: the browser tests titled `[R…]` for this slice and the ones
    before it, at the app's one address. **The app** and a **Service** have no journey of their own, so
    their verification ends at step 5 (and needs no browser test runner); each feature walks its own.
@@ -501,8 +529,10 @@ the code holds, a verification of the code as it is now, and what the runtime se
 Only **Verified** is green, and only on evidence about the code as it is now. Change the code and earlier
 evidence is out of date: green parts go back to **Connected** (if the runtime still finds them answering)
 or **Built** until a slice through them is verified again; red clears the same way. An outside service
-that Albert uses a stand-in for stays **Built** until its own slice connects the real one. Select a part
-or a connection to read why it has its status. Parts no feature needs show their check, as before.
+that Albert uses a stand-in for stays **Built** until its own slice connects the real one. A line to a
+part a later slice builds (the API's line to CI, say) waits for that slice, and does not hold back the
+parts and features verified before it. Select a part or a connection to read why it has its status.
+Parts no feature needs show their check, as before.
 
 **Example.** In the notes app, *The app runs* passes: Web app and API turn **Connected**, because they
 answer but no journey has gone through them yet. *Add SQLite* passes: SQLite turns **Connected** too.
@@ -594,9 +624,31 @@ that reloads by itself.
 - **Recovery.** A part that stops by itself is started again after 2, 5 and 10 seconds: at most three
   times in ten minutes, then it is left stopped with the reason. A dev server that reloads after a bad
   edit is not restarted: it answers again once the code is fixed.
+- **Started again, never twice.** Pressing **Start all** while the app runs leaves alone each part
+  that works and still has the right addresses. A part that runs but does not work, or that started
+  before a service it uses was connected on the map (or before a part it reaches moved to another
+  port), is stopped and started again in its place, never beside itself. So is a part whose code has
+  changed since it started and that does not reload by itself: a Celery worker, a `start` script or a
+  command of your own (dev servers such as `next dev`, `vite`, `uvicorn --reload`, Flask in debug mode
+  and Django's `runserver` reload by themselves). A verification does the same before it checks
+  anything, so no part is judged by an address it was never given, or by code it is not running. Its
+  log says why:
+
+  ```text
+  API  Starting it again: what it reaches has changed since it started
+  API  $ python3 -m uvicorn main:app --host 127.0.0.1 --port 8000 --reload  (in api)
+  API  INFO:     Application startup complete.
+  ```
 - **Install packages.** A part whose packages are missing says so before it starts, with the exact
   command: **Install packages** runs it (`npm install` or your package manager; for Python, a `.venv`
-  and `pip install`). A failed install says why, for example a network that needs a proxy.
+  and `pip install`). A failed install says why, for example a network that needs a proxy. For a
+  Python part, every package its `requirements.txt` (or `pyproject.toml`) lists is checked, not only
+  its framework, so a package added in a later step is found before the part starts:
+
+  ```text
+  Workers  Its packages are not installed
+           Declared in its project but not installed: redis. Install packages runs it for you.
+  ```
 - **Logs.** The **Log** section shows what every part prints, or one part's, with errors marked. Keys
   are masked. **Its log** on a part jumps to it.
 - **Fix with Albert** on a part that fails sends Albert how it was started, what it printed and what

docs/troubleshooting.md

@@ -66,10 +66,13 @@ Everything an installer run did is written to its log:
 | **Install packages** fails with a certificate or network error | Your network needs a proxy or its own certificates. Set `HTTPS_PROXY` (and `SSL_CERT_FILE`, `PIP_CERT` or `NODE_EXTRA_CA_CERTS` if your company gives you a certificate) in your terminal, run `albertcode stop`, then start `albertcode --ui` from that terminal. |
 | A database in `docker-compose.yml` is not started | AlbertCode does not start containers. Run `docker compose up -d` yourself, then **Connect** the database on the map: its check decides when it is up. |
 | Redis says it cannot be started | Install Redis (`redis-server`) and press **Start all** again, or connect a Redis you already run on the map. |
+| A part does not use a service you just connected | It was started before the connection. Press **Start all**: each part started before it is started again with the service's address (a verification does this for you). |
 | A part is **Running** but not **Healthy** | Nothing proves it works: give it a health route (`/health`) or, for a worker, a ready line it prints, in **How it runs**. |
 | A part is **Unhealthy** right after a change | Its code fails to load: read its log in **Operate** → **Run**, or press **Fix with Albert** on it. The dev server picks up the fix by itself. |
 | A part **Crashed** and stays stopped | It stopped three times within ten minutes. Read its log, fix the cause, then **Start**. |
 | The app's address keeps showing *Starting…* | A part is still starting or waiting for a part it needs. **Operate** → **Run** says which, and why. |
+| **Verify** stops at *Install what the app needs: A browser for the tests*, though Chrome, Edge or Chromium is installed | The browser tests were started without a browser of Playwright's own, and your `playwright.config.ts` does not use the one AlbertCode found. Under `use`, add `launchOptions: process.env.PW_CHROMIUM_PATH ? { executablePath: process.env.PW_CHROMIUM_PATH } : {}` (new slices ask Albert for it), or press **Install** to download Playwright's own Chromium. Nothing in the app is repaired for it. |
+| **Verify** stops at *Start the app* or *Check each connected service*: a service *is not answering where it is connected* | A service you connected on the map (your database, say) is down, or not where its connection says. Start it, or change its connection on the map: once its check passes, **Verify** again. Nothing in the app is repaired for it. |
 | **Verify** fails at *Walk every journey*: no browser test walks [R1] yet | The slice needs a browser test titled `[R1] …`. Build the slice (its request asks for one), or **Add a test** on the Requirements page. |
 | The **Build** stage says *the code has changed since* | The last verification was of older code. Press **Verify** again. |
 | **Roll back** says there is no checkpoint yet | A checkpoint is kept each time a slice passes its verification, and only in a Git repository. Run `git init` and commit, then verify a slice. |