@thebackstoryis/engineering-with-ai 0.2.9

package/Docs/team-hub-guide.md

@@ -0,0 +1,162 @@
+# Team Hub guide
+
+Team Hub is EWAI's optional, self-operated team visibility layer. Every project remains in **single mode** by default: delivery runs locally, SPECS stay local, and no network service is required. A contributor may deliberately connect a project and publish a bounded read-only snapshot to a separately running Team Hub.
+
+```text
+local EWAI project ── explicit bounded snapshot ──> Team Hub service
+       │                                                │
+       └── full local delivery authority                └── read-only portfolio
+```
+
+The service is an operational projection, not a replacement for Git, SPECS, the project-local dashboard or an engineering work-management system. It cannot approve Build or Manual QA, accept risk, certify compliance, deploy or release.
+
+Team Hub's shared view isn't remote access to each project's editing dashboard. Contributors work in their local project, then explicitly publish the permitted summary. To review or edit a local draft together, work on the owner's computer or use an approved screen-sharing process.
+
+## What the first release provides
+
+- Single-contributor operation with no service, token or network dependency.
+- An exact disclosure contract that identifies included fields and excluded categories.
+- A local connection that stores an endpoint, project identifier, disclosure digest and token environment-variable **name**—never the token value.
+- Explicit snapshot publication with an immutable local attempt record.
+- A digest-bound receipt when the service accepts a snapshot. Acceptance is transport evidence, not delivery approval.
+- A separate SQLite-backed service with an authenticated ingestion endpoint and read-only portfolio UI.
+- An optional immutable registry for validated Organisation Blueprint and design-system releases.
+- Separate reader and publisher credentials, with publishing disabled unless an operator configures it.
+- Exact-version, exact-digest local installation with quarantine validation, rollback and local receipts.
+- CLI and local-dashboard controls for disclosure, connection, publication status and disconnection.
+
+It does not provide central intent editing, central gate actions, premium persona bodies, source code, SPECS bodies, enterprise identity, managed hosting, licensing, automatic synchronisation or production execution. Installing a governed resource makes it locally available; it does not select, apply or approve it.
+
+## Operate a hub
+
+Choose a dedicated local-disk directory outside every EWAI project. Do not use `.ewai-pipeline`, a repository folder, a cloud-synchronised folder or a network share. Set a long random bearer token in an environment variable, then start the separate service:
+
+```bash
+export EWAI_TEAM_HUB_TOKEN='replace-with-a-long-random-reader-secret'
+export EWAI_TEAM_HUB_PUBLISHER_TOKEN='replace-with-a-different-publisher-secret'
+ewai team-hub start \
+  --data /srv/ewai-team-hub \
+  --token-env EWAI_TEAM_HUB_TOKEN \
+  --publisher-token-env EWAI_TEAM_HUB_PUBLISHER_TOKEN \
+  --host 127.0.0.1 \
+  --json
+ewai team-hub status --data /srv/ewai-team-hub --json
+```
+
+Loopback is the safe default. A non-loopback bind requires `--allow-network`. The built-in service is HTTP-only; for any shared network deployment, put it behind an organisation-managed **TLS reverse proxy**, terminate HTTPS there, restrict network access, and use an HTTPS contributor endpoint. EWAI does not configure the proxy or certify the resulting deployment.
+
+Open the URL returned by `start`. The central browser UI asks for a reader or publisher bearer token for the current tab only and holds it in session storage. The service state file records environment-variable names, never credential values. Omit `--publisher-token-env` when this hub must remain read-only.
+
+Stop the service with:
+
+```bash
+ewai team-hub stop --data /srv/ewai-team-hub --json
+```
+
+## Connect a contributor project
+
+First review the current disclosure:
+
+```bash
+ewai team disclosure --project . --json
+```
+
+Then make the token available under the variable name agreed with the operator and connect. Connection does not publish a snapshot.
+
+```bash
+export EWAI_TEAM_HUB_TOKEN='the-operator-supplied-secret'
+ewai team connect https://hub.example.org \
+  --project-id claims-platform \
+  --token-env EWAI_TEAM_HUB_TOKEN \
+  --acknowledge-disclosure \
+  --yes \
+  --project . \
+  --json
+ewai team status --project . --json
+```
+
+The same controls are available in the local dashboard's **Team Hub** view. Enable it in **Configuration** and save first; see [dashboard configuration](operations/dashboard-configuration.md). Showing the view doesn't connect the project. The dashboard accepts only the endpoint, project ID, token environment-variable name, explicit confirmation and disclosure acknowledgement. It cannot accept a project-root override or a token value.
+
+## Publish a snapshot
+
+Publication is always deliberate:
+
+```bash
+ewai team sync --yes --project . --json
+```
+
+The local dashboard has an equivalent **Publish current snapshot** action with a confirmation step. Each action writes an attempt record. When accepted, a separate receipt records the project ID, snapshot digest, idempotency key, acceptance time and whether the same snapshot was replayed.
+
+A failed attempt does not remove the last accepted receipt. This lets an operator distinguish “the latest network attempt failed” from “this is the last snapshot the hub actually accepted.” Local engineering work remains available in either case.
+
+## Distribute governed resources
+
+An operator can publish immutable `org.*` Organisation Blueprint and design-system releases. Connected contributors can discover release metadata, inspect an exact release, and explicitly install it by version and SHA-256 digest. Publication and installation have separate receipts, and a failed update restores the previously installed release.
+
+The registry does not carry premium persona bodies or governed starter-project executable material. A Blueprint can reference those capabilities by identity, while their own entitlement and materialisation controls remain authoritative. Installing a release does not activate it or change SPECS.
+
+See the [Team Hub Resource Registry guide](team-hub-resource-registry-guide.md) for publisher configuration, packaging rules, contributor commands, dashboard operation, collision handling, offline cache replay, restoration and audit evidence.
+
+## Disclosure and data custody
+
+The snapshot uses a closed allow-list. Inspect the command output for the authoritative current list. At this release it contains bounded project identity, package version, a one-way repository-revision digest, intent counts, a compact latest-delivery status, selected reusable-resource identities and digests, timestamps, attention signals and the authority notice.
+
+The snapshot excludes:
+
+- credentials and environment-variable values;
+- source code and SPECS document bodies;
+- persona bodies, prompts and transcripts;
+- logs and error-report packages;
+- repository remotes and local filesystem paths.
+
+Unknown fields are rejected on both the contributor and service sides. Snapshot and envelope digests are recomputed before storage. Treat the resulting database as internal operational metadata and apply your organisation's retention, access-control and incident-response policy.
+
+## Token rotation
+
+To rotate the shared token:
+
+1. Stop the Team Hub service.
+2. Replace the value in the configured environment variable.
+3. Start the service again using the same variable name.
+4. Update that environment variable for authorised contributors.
+5. Run an explicit sync from one project and verify a new accepted receipt.
+
+The connection files do not need changing when the environment-variable name remains stable. For a staged rotation, run a second hub endpoint or coordinate a maintenance window; the first release intentionally supports one active shared bearer token per service.
+
+## Backup and recovery
+
+The service database is under `<data-root>/data/team-hub.sqlite`; runtime state and logs are kept in sibling directories. For a simple consistent backup:
+
+1. Run `ewai team-hub stop --data <data-root>`.
+2. Copy the entire dedicated data root using your approved backup process.
+3. Restart the service and confirm `status` is `running`.
+
+For live backups, use a SQLite-aware backup tool and include write-ahead-log state correctly. Do not assume that copying only the main database file while the service is writing produces a recoverable backup.
+
+To recover, stop the service, restore the dedicated data root to local disk with restrictive permissions, set the token environment variable, start the service, and verify `/health`, the portfolio UI and a deliberate contributor sync. The hub can also be rebuilt from future contributor snapshots; it is not the canonical source of delivery truth.
+
+## Disconnect a project
+
+```bash
+ewai team disconnect --yes --project . --json
+```
+
+Disconnect removes only the active local connection. It does not delete local attempt history or the last accepted receipt, and it cannot recall data already accepted by a hub. The project immediately returns to single-contributor mode. Hub-side deletion and retention remain operator responsibilities in this release.
+
+## Troubleshooting
+
+- **Token environment variable is unavailable:** export the variable named by `ewai team status`, then retry. Do not put the token in a command argument or project file.
+- **HTTP endpoint rejected:** shared endpoints must use HTTPS. Plain HTTP is accepted only for loopback development.
+- **Snapshot rejected:** inspect the local attempt record and service log. Correct the cause and publish again; do not edit attempt or receipt files.
+- **Service reports stale:** stop it, inspect the configured data-root log, and start it again. A stale state file is never treated as a healthy service.
+- **Contributor is offline:** continue working locally. No gate or project operation depends on Team Hub availability.
+
+## Operational verification
+
+If you're maintaining the harness, see the [Team Hub verification notes](maintainers/verification-walkthroughs.md#team-hub) for the automated suites and commands.
+
+Automated success is engineering evidence, not Manual QA or operational acceptance. Before a shared deployment, an accountable operator must still verify the chosen TLS proxy, identity and access controls, backup and restore procedure, retention policy, monitoring, service ownership, narrow-screen usability, keyboard operation and one real contributor-to-hub journey in the target environment.
+
+## Authority and deployment responsibility
+
+Team Hub remains read-only with respect to project truth and delivery authority. Its optional resource registry distributes immutable validated releases; installing one doesn't select or apply it. The organisation operating the Hub is responsible for its deployment, access controls, retention and recovery. Verify those controls in the target environment before inviting contributors.

package/Docs/team-hub-resource-registry-guide.md

@@ -0,0 +1,167 @@
+# Team Hub Resource Registry guide
+
+The Team Hub Resource Registry distributes immutable, organisation-owned EWAI working
+material without turning the Hub into project authority. The first release supports
+Organisation Blueprint packs with `type: organisation` and design-system packs with
+`type: design-system`, both using strict `ewai.pack/v1` manifests and `org.*` IDs.
+
+Blueprints may reference ordinary local project personas, policies, standards,
+design-system IDs and governed starter metadata. The registry transports the Blueprint
+manifest and its referenced policy, persona and standard text files. It does **not**
+retrieve starter source, execute adapters, or distribute premium persona bodies.
+
+```text
+author pack -> validate -> publish immutable release -> discover -> inspect
+                                                          |
+                                                          v
+                      select/apply separately <- install exact verified digest
+```
+
+Publication means a release is available. Installation means the bytes are available
+inside one project's managed pack root. Neither action selects a design system, applies
+a Blueprint, changes SPECS, approves Build, accepts risk or approves release.
+
+## Configure reader and publisher authority
+
+Use different long random values and different environment-variable names:
+
+```bash
+export EWAI_TEAM_HUB_READER_TOKEN='replace-with-a-long-random-reader-secret'
+export EWAI_TEAM_HUB_PUBLISHER_TOKEN='replace-with-a-different-publisher-secret'
+
+ewai team-hub start \
+  --data /srv/ewai-team-hub \
+  --token-env EWAI_TEAM_HUB_READER_TOKEN \
+  --publisher-token-env EWAI_TEAM_HUB_PUBLISHER_TOKEN \
+  --host 127.0.0.1 \
+  --json
+```
+
+The reader can list and download releases and can continue to publish bounded project
+snapshots. It cannot publish a governed resource. The publisher can publish and inspect
+resources. The service stores only the environment-variable names in service state.
+Starting without `--publisher-token-env` keeps the original portfolio capability and
+returns an explicit `publisher-not-configured` response for resource publication.
+
+## Prepare a resource
+
+Start from a folder that already validates with EWAI's organisation Blueprint or
+design-system tooling. A package contains only `pack.yaml` and local files directly
+referenced by Blueprint standards, personas and policies or by design-system
+contributions.
+
+Allowed file extensions are `.md`, `.yaml`, `.yml`, `.json`, `.txt`, `.toml` and `.css`.
+The registry rejects hidden or escaping paths, symlinks, invalid UTF-8, binary NUL
+content, executable/archive types, more than 100 files, a file over 256 KiB, or total
+content over 2 MiB. This is deliberately narrower than the normal local pack limits.
+
+Use a new semantic version when content changes. The registry will not accept different
+bytes under an existing resource ID and version.
+
+## Publish an immutable release
+
+```bash
+ewai team-hub resource publish ./packs/acme-delivery \
+  --data /srv/ewai-team-hub \
+  --publisher-token-env EWAI_TEAM_HUB_PUBLISHER_TOKEN \
+  --publisher-name "Acme Engineering" \
+  --yes \
+  --json
+```
+
+Organisation Blueprint publisher identity comes from its manifest. A design-system
+publisher name comes from `--publisher-name`; its publisher ID is the organisation
+segment of the `org.*` pack ID. Successful publication returns a package digest and an
+immutable publication receipt. Repeating the exact release is idempotent. Different
+content under the same ID/version returns a conflict.
+
+The central Team Hub browser shows the retained release catalogue after a reader or
+publisher credential is entered for the current tab. It deliberately does not provide
+project installation or activation controls.
+
+## Discover and inspect from a project
+
+Connect the project using the **reader** token as described in the Team Hub guide, then:
+
+```bash
+ewai team resources --project . --json
+ewai team resource inspect org.acme.delivery 1.0.0 --project . --json
+```
+
+Discovery returns safe release metadata, not package bodies. Inspect downloads and
+validates one exact package for review but does not write it to the pack root. The local
+dashboard provides equivalent **Refresh resources** and inspect controls. Nothing is
+queried automatically during check-in or ordinary dashboard load.
+
+## Install an exact release
+
+Copy the digest from the catalogue or inspection result and name the accountable person
+or role:
+
+```bash
+ewai team resource install org.acme.delivery 1.0.0 \
+  --expected-digest sha256:REPLACE_WITH_THE_EXACT_DIGEST \
+  --approved-by "Platform Owner" \
+  --yes \
+  --project . \
+  --json
+```
+
+EWAI downloads the exact release if it is not already cached, verifies every file and
+the aggregate digest, reconstructs it in a private quarantine, runs the existing pack
+parser, checks for an outside-owned ID collision, then atomically exposes one managed
+active copy under `.ewai-pipeline/packs/team-hub/`. Immutable cached versions remain
+outside pack discovery.
+
+An install receipt records the prior and installed version/digest, action, approver and
+time. View safe history with:
+
+```bash
+ewai team resource receipts --project . --json
+```
+
+After installation, use the normal Blueprint preview/apply or design-system
+inspect/resolve/select workflow. The registry never performs that next decision for you.
+
+After installation succeeds, use the relevant adoption workflow:
+
+- Design-system pack: [resolve and select it](design-systems/design-system-user-guide.md#select-a-project-design-system), then apply it to a delivery.
+- Organisation Blueprint: [review it in Guided Setup](designing-organisation-blueprint-packs.md#review-and-approve-in-guided-setup) and approve its project consequences.
+
+An install receipt isn't either selection decision.
+
+## Restore, offline use and recovery
+
+Install an older exact version with its digest to perform a deliberate restore. If that
+release is already in the immutable cache, the install can complete while the Hub is
+offline. The cache is not a discovery catalogue and EWAI never chooses a cached update
+automatically.
+
+Active-copy promotion uses a bounded backup. If validation or promotion fails, EWAI
+restores the prior active pack and does not write a success receipt. If an ID already
+exists in bundled, personal or non-managed project packs, installation stops and leaves
+that content untouched.
+
+Only one install may mutate a project resource workspace at a time. EWAI holds a
+process-owned local lease across download, quarantine, cache, promotion, state and
+receipt publication. A live owner produces a stable `resource-install-busy` refusal;
+a dead owner, or sufficiently old malformed lease metadata, is recovered on the next
+explicit install. EWAI never breaks a lease belonging to a live process merely because
+it is old.
+
+To recover operational state, restore the project-local `.ewai-pipeline/team-hub/resources`
+and `.ewai-pipeline/packs/team-hub` folders together from an approved backup. Do not edit
+installed state or receipts by hand. Re-inspect and install the exact retained digest if
+the cache or managed copy cannot be trusted.
+
+## Registry assurance tests
+
+EWAI maintainers can find the automated coverage, browser checks and commands in [Registry verification](maintainers/verification-walkthroughs.md#team-hub-resource-registry). Those checks don't replace your organisation's decision to adopt a resource or its deployment checks.
+
+## Current boundaries
+
+This release does not support technology/stack/core packs, standalone persona packs,
+premium persona distribution, signatures, assignments, revocation, automatic updates,
+central approval, multi-user editing, remote code execution, EDD licensing, deployment,
+npm publication or release acceptance. A Team Hub receipt is operational evidence, not
+certification that a pack is safe, correct or suitable for a project.

package/Docs/tutorials/first-delivery.md

@@ -0,0 +1,83 @@
+# Work through your first feature
+
+Follow one fictional feature from a rough request to a reviewed delivery: **export the filtered support-ticket list as CSV**. This is a guided exercise, not a claim that the commands below generate a finished application.
+
+Start with [your first session](first-session.md). To implement an export, you'll need a small working ticket-list application; otherwise use the exercise to plan the feature and stop before Build. You and EWAI must inspect the actual stack and existing behaviour before choosing code or tests.
+
+## Ask for an outcome
+
+In your AI host, say:
+
+> “We need support colleagues to export the filtered ticket list as a CSV. Work through the intent with us using ewai-deliver. Stop before implementation so we can review the plan.”
+
+The **ewai-deliver skill** coordinates the stages. The runtime records progress and checks the evidence; it doesn't replace the conversation or make your decisions.
+
+A draft intent can start this workflow. Before the Intent stage finishes, agree who can export, which filters and columns apply, which data must be excluded, and how you'll recognise a correct result. Don't treat an AI suggestion as an agreed requirement.
+
+For example, you might agree that an authorised colleague can export the filtered rows while a colleague without export permission cannot. Those are tutorial choices: the people responsible for a real project must choose its rules.
+
+## Find the saved work
+
+Ask EWAI for the intent's identifier and location. An identifier such as `support/export-filtered-tickets` identifies one item; use the identifier actually returned for your project.
+
+You can inspect the next step directly:
+
+```bash
+ewai delivery continue support/export-filtered-tickets --project .
+```
+
+This command **reports the next permitted step** for an existing delivery. It doesn't make the assistant perform that step. Ask the host to continue the work.
+
+At each review, open the linked evidence in SPECS. You should be able to see what was agreed, what remains uncertain and why the next action is allowed or blocked.
+
+## Work through the plan
+
+Follow [the fourteen-stage explanation](../explanation/delivery-workflow.md) alongside the conversation. For this feature, the important questions include:
+
+- Does export use the same filters and permissions as the screen?
+- Which fields could expose data the recipient shouldn't receive?
+- What happens with no matching rows or an export request that fails?
+- Does the proposed implementation fit this application's patterns?
+- Which checks require a person, rather than an automated test?
+
+Where interface work is needed, review and select a prototype during UI Design. Selecting it isn't permission to implement it or acceptance of the finished feature.
+
+EWAI prepares test expectations from the accepted requirements. Check that the tests prove the behaviour you agreed, rather than a new assumption. If an independent reviewer isn't available, the relevant external stage remains `not-supported`; a host's review of its own work isn't independent validation. The standards sweep still applies.
+
+## Pause without losing the plan
+
+If you want to plan now and build later, ask for shelf mode **when starting the delivery**:
+
+> “Prepare the export feature in shelf mode. We'll review it before Build.”
+
+When returning to that shelved work, ask EWAI to resume it. EWAI performs a **Fit Check** before Build to establish whether the plan still fits the project. A changed permission model, dependency or requirement may require a revised plan rather than immediate implementation.
+
+For any ordinary pause, return to the same project and ask where the saved work stands. Don't rewrite delivery-state files to force progress.
+
+## Approve a bounded implementation
+
+Only approve Build when you're satisfied with the proposed scope and evidence. For example:
+
+> “We approve implementing the filtered CSV export described in this plan, including the permission checks and planned tests. Don't add scheduled exports or change other permissions.”
+
+That approval applies to the agreed work, not every improvement discovered during implementation. EWAI records it before Build can begin. The [delivery guide](../developer-delivery-guide.md#preserve-the-build-approval-boundary) explains the direct approval command.
+
+During Build, inspect the actual changes and tests. A failing check needs an explanation and a fix within scope—or a new decision—not a rewritten result. Your unrelated edits remain outside the approved change.
+
+## Try the failure case as well as the success
+
+In the implemented example, an authorised colleague should receive only the accepted filtered columns and rows. Also try the agreed denied-access case.
+
+If a colleague without export permission can download the file, the feature hasn't passed that acceptance check, even if the happy path works. Record what happened and ask EWAI to trace the failure against the accepted requirement. Don't mark Manual QA approved while that requirement is failing.
+
+Test data and permissions must be safe and fictional. Don't use a real customer's records to prove this exercise.
+
+## Finish with a human decision
+
+After automated checks and configured reviews, Delivery provides the changes, results, known limits and a **Manual QA walkthrough**. A named person performs or accepts that walkthrough and records the observed result. The assistant can't supply human acceptance on their behalf.
+
+Retro follows Manual QA and captures reusable learning—for example, a missing CSV safety test or a useful export pattern. Completing Delivery or Retro doesn't itself authorise deploying the application.
+
+**Your result:** a traceable feature whose requirements, decisions, implementation, tests and acceptance can be inspected. If you stopped at planning, the result is a reviewed plan, not a delivered feature.
+
+Next: [developer delivery operations](../developer-delivery-guide.md), [human approval](../human-approval-and-assurance-guide.md), or [recovery when a step is blocked](../operations/troubleshooting-and-recovery.md).

package/Docs/tutorials/first-session.md

@@ -0,0 +1,62 @@
+# Your first EWAI session
+
+Set up a small, disposable project and find out what EWAI saves for you. You don't need an existing application, a Blueprint or a premium-persona subscription.
+
+You'll need [EWAI and its host skills installed](../operations/installation-updating-and-entitlements.md). This tutorial uses a fictional support-ticket tool. It won't create a production service or require customer data.
+
+## 1. Open an empty project
+
+Create an empty folder called `ewai-support-demo` somewhere you keep test projects. Open it in your supported AI host. Ask:
+
+> “Start EWAI here. We're trying it with a small support-ticket tool.”
+
+The first setup choice is where to keep SPECS, the project's readable knowledge folder. For this single-folder example, choose `SPECS` inside the project. Don't choose an unrelated existing knowledge folder.
+
+After initialisation, you should be able to find `SPECS/` and `.ewai-pipeline/project.json`. The latter points EWAI to the chosen knowledge location. Creating those files isn't the same as agreeing the project's requirements.
+
+If you prefer terminal setup, run this **inside the empty example folder**, then return to the host conversation:
+
+```bash
+ewai init --project . --name "Support demo" --codex
+ewai doctor --project . --json
+```
+
+Use the host option appropriate to your installation. Doctor reports configuration problems; don't use `--force` as a shortcut around one.
+
+## 2. Choose how much setup you need
+
+For this exercise, the project is new: there is no existing code to investigate. In a real existing project, EWAI should offer **Archaeology**, which reconstructs missing documentation from evidence. You can decline it and continue through Discovery, recording what you haven't investigated.
+
+Premium personas are optional. If you have a licence and want their perspectives in the analysis, [set it up privately](../operations/premium-personas-setup.md) and wait for the installation confirmation before continuing. Don't enter the key in this conversation. Without a licence, continue with the included personas.
+
+You don't need Team Hub, Portfolio or an Organisation Blueprint for this exercise. Accepted project standards and approval gates still apply.
+
+## 3. Describe the project
+
+Tell EWAI:
+
+> “Support colleagues need to record tickets, filter their queue and export the filtered list. For now we're exploring the export. We haven't chosen the application stack. No real customer data belongs in this demo.”
+
+Answer questions about the people, outcome, scope and constraints. It's fine to say “we haven't decided” where that's true. Don't accept an invented requirement just to complete a field.
+
+Ask EWAI to show you the drafted project purpose and requirements in SPECS. Check that they describe the support colleagues' needs, distinguish unresolved choices and don't claim an application already exists.
+
+**Your observable result:** a local knowledge structure, draft project context and a clear next decision. The exact assistant wording will vary with your host; generated text isn't automatically approved project truth.
+
+## 4. Open the dashboard
+
+Ask EWAI to open the project dashboard. Use the loopback URL returned for this project; its port can vary.
+
+The dashboard lets you inspect saved work and make supported choices. The host conversation performs the guided work. Opening the dashboard doesn't silently start a delivery.
+
+The URL begins with `127.0.0.1` and works on the computer running EWAI. A colleague needs to work with you locally or through screen sharing; sending that URL alone won't give them access.
+
+## 5. Check where you are, then stop
+
+Ask:
+
+> “Show us what's saved, which decisions are still open, and what we'd do next. Don't implement anything.”
+
+You should be able to distinguish your draft from an approved intent and find the saved records. If the host can't find its skills, restart it after checking the [host installation](../operations/installation-updating-and-entitlements.md). If Doctor reports inconsistent state, use [recovery guidance](../operations/troubleshooting-and-recovery.md), not manual database edits.
+
+You can close the session here. Later, open the same folder and ask EWAI to pick up the saved project. For a delivery exercise, continue with [your first feature](first-delivery.md).