@webship.co/workspace-odoo 0.0.0-stage → 1.0.7

package/README.md

@@ -1,3 +1,187 @@
-# Temporary Holding Version
+# @webship.co/workspace-odoo
 
-This version is a temporary placeholder for this package. An operational version to replace this has been submitted for review and is awaiting a staged release.
+Odoo Community for the [Webship Workspace](https://github.com/webship/workspace) dashboard: a
+builder that makes a real Odoo site in containers, an odoo-bin tool for the sites it built, the
+default accounts, the [Odoo step pack](https://github.com/webship/odoo-steps) wired into the
+workspace's testing setup, and two AI agents that know all of it.
+
+The workspace is container-based (DDEV by default): an Odoo project is a row like any other, so
+the row menus the core draws (start, stop, launch, backup, clone, remove, tests) work on it
+unchanged.
+
+It is Odoo Community: never the Enterprise edition, no trial, no licence and no vendor account.
+The module that sends what a user types to an outside service (`partner_autocomplete`) is
+uninstalled when the database is created.
+
+The plugin is made from the reference platform plugin,
+[`@webship.co/workspace-wordpress`](https://github.com/webship/workspace-wordpress); what differs is
+what Odoo needs, see [What is different from a PHP platform](#what-is-different-from-a-php-platform).
+
+## Use it
+
+```bash
+cd ~/workspace
+bash core/scripts/plugins.sh --require github:webship/workspace-odoo   # npm install into the dashboard
+bash core/scripts/plugins.sh --activate odoo                            # plugins.odoo in settings.yml
+bash core/scripts/plugins.sh --install odoo                             # commands, functions, args, agents
+bash core/scripts/plugins.sh --configure odoo                           # nothing to configure: it has no settings file
+```
+
+The same four steps are buttons on the dashboard's **Settings → Plugins** page. `--install` is
+idempotent. `--uninstall` removes what it placed; an agent you edited stays.
+
+The commands land in the sites folders that are in the workspace (`dev`, `test`, `sandboxes`,
+`demos`); the agents land in the AI Agents folder (`ai-agents/`) when the workspace has one, and are
+installed into `~/.claude/agents` from there like any other agent.
+
+The agents, the builder's flags in the Build form and the step pack in the testing setup need a
+Webship Workspace after 1.0.6.
+
+## This builder and `cmd-odoo20-project.sh`
+
+The sites folders of the workspace (the `dev`, `test` and `sandboxes` folder plugins) carry an
+example builder of their own, `cmd-odoo20-project.sh` (**Odoo 20 Community** in the Build list),
+with its functions in the core (`build_odoo` in `core/scripts/functions/fun-odoo.sh`). It shows how
+a platform that is not PHP is built: Odoo 20 with the base module, behind the web container's own
+web server.
+
+This plugin leaves that example exactly as it is, and the two can be in a folder together:
+
+| | `cmd-odoo20-project.sh` (the folder's example) | `cmd-odoo-project.sh` (this plugin) |
+| --- | --- | --- |
+| In the Build list | Odoo 20 Community | Odoo 17 Community (apps, accounts, tests) |
+| Release | 20.0, fixed | 17.0 by default (the release the step pack is proven on); `--version` names another tag of the image |
+| What `--install` makes | The base module | The apps (Contacts, CRM, Sales, Invoicing, Website with blog, shop, events, jobs) with demo data, the workspace account as the administrator, the module that calls an outside service uninstalled |
+| How it is served | The web container's web server proxies to Odoo | The router serves Odoo's port; Odoo runs with `--proxy-mode` and a `--db-filter` |
+| Accounts | The administrator | The administrator, and with `--add-users` the default accounts |
+| Tool, tests, agents | None | `cmd-tools-odoo-cli.sh`, the Odoo step pack in `cmd-tools-testing.sh`, `odoo-site-builder` and `odoo-tester` |
+| Functions | `build_odoo`, `odoo_cli`, `odoo_write_compose`, `odoo_write_nginx` (the core's) | `odoo_build`, `odoo_bin`, `odoo_cli_tool` and the rest in `fun-odoo.sh` of the plugin: none of the core's names is defined again |
+
+The commands have different names, so neither replaces the other. The plugin's tool, its accounts
+and its testing setup work on the projects `cmd-odoo-project.sh` built (they carry
+`.ddev/config.odoo.yaml`) and refuse the others, a project of the example builder included.
+
+## What the package holds
+
+| Path | What it is |
+| --- | --- |
+| `commands/cmd-odoo-project.sh` | The builder, in the Build list as **Odoo 17 Community (apps, accounts, tests)**, installed into every sites folder |
+| `commands/cmd-tools-odoo-cli.sh` | odoo-bin for one project: what the site is, a command, apps, an update, a restart, the default accounts |
+| `scripts/functions/fun-odoo.sh` | The bash functions behind both, sourced by bootstrap once installed; the names the core's tools look for (`set_odoo_users`, `add_odoo_users`, `cancel_odoo_users`, `testing_configure_odoo`) |
+| `scripts/args/arg-odoo.sh`, `arg-odoo-cli.sh` | Their argparse; the Build form draws the builder's flags from the first |
+| `scripts/odoo-accounts.py` | The administrator, the default accounts and what keeps the site local, run in the Odoo shell of the project |
+| `testing/site.feature` | The first feature an Odoo project gets when testing is set up |
+| `agents/odoo-site-builder.md` | The agent that builds and maintains Odoo sites with these commands |
+| `agents/odoo-tester.md` | The agent that writes and runs scenarios with the Odoo step pack |
+| `src/index.ts` | `register(api)`: what the assistant is told about Odoo here |
+| `features/odoo.feature` | Scenarios for the dashboard's own browser suite |
+
+The `workspacePlugin` block in `package.json` is the manifest the installer reads.
+
+## What is different from a PHP platform
+
+Odoo is a Python application that ships as a container image, and DDEV has no project type for
+it. The plugin keeps the shape of the reference and changes only this:
+
+| | WordPress (the reference) | Odoo |
+| --- | --- | --- |
+| Project | `--project-type=wordpress`, nginx and PHP | `--project-type=generic --webserver-type=generic`; Odoo is a service of the project (`.ddev/docker-compose.odoo.yaml`, the official Community image) and the router serves its port |
+| Recognised by | The DDEV project type | The file `.ddev/config.odoo.yaml` |
+| Database | The container tool's default, settings written by the tool | PostgreSQL 16 from the container tool; the compose file carries the container's own `db` / `db` / `db`, and the one database is `db` |
+| Getting the code | `wp core download` | The container image `odoo:<version>` |
+| Install | `wp core install` | `odoo-bin -i <apps>` on the database, then the workspace account is set on the administrator |
+| Accounts | WP-CLI | A script run in the Odoo shell (`scripts/odoo-accounts.py`) |
+| Users menu of the row | Reads the project type | Does not apply (no project type): `cmd-tools-odoo-cli.sh --add-users`, or `cmd-tools-add-users.sh <name> odoo` |
+
+## The commands
+
+Run them from a sites folder. `--help` is safe on both.
+
+### Build a site
+
+```bash
+cd ~/workspace/dev
+bash cmd-odoo-project.sh mysite --install --add-users
+```
+
+| Flag | What it does |
+| --- | --- |
+| `--version <x>` | The release to run, as the image is tagged. `17.0` is the default and the one the apps, the accounts and the step pack are proven on; another tag is yours to try |
+| `--install` | Create the database with the apps and the demo data, with the workspace account as the administrator |
+| `--add-users` | With `--install`: add the default accounts |
+| `--apps <a,b>` | The apps `--install` installs, by their technical names (the default: `contacts,crm,sale_management,account,website,website_blog,website_sale,website_event,website_hr_recruitment`) |
+| `--without-demo` | With `--install`: leave the demo data out |
+| `--launch` | Open the site when it is ready |
+
+The site answers at `https://mysite.ddev.site`, the login at `/web/login`. Custom modules go in the
+project's `addons/` folder. A project of the same name is deleted first. The first build pulls the
+image, and the install of the default apps with demo data takes several minutes.
+
+### Work on a site
+
+```bash
+bash cmd-tools-odoo-cli.sh mysite                                    # version, address, apps, accounts
+bash cmd-tools-odoo-cli.sh mysite --install-apps project,hr          # install apps, then start Odoo again
+bash cmd-tools-odoo-cli.sh mysite --update                           # odoo-bin -u all, then start Odoo again
+bash cmd-tools-odoo-cli.sh mysite --run "-u sale --stop-after-init"  # any odoo-bin arguments
+bash cmd-tools-odoo-cli.sh mysite --run=--version                    # one argument that starts with a dash: with an equals sign
+bash cmd-tools-odoo-cli.sh mysite --restart                          # start Odoo again and wait for it
+bash cmd-tools-odoo-cli.sh mysite --add-users                        # the default accounts
+bash cmd-tools-odoo-cli.sh mysite --cancel-users                     # delete them, or archive what Odoo keeps
+```
+
+### The default accounts
+
+| Account | What it may do | Handle in the tests |
+| --- | --- | --- |
+| `administrator` | Every installed app, and the settings | `admin` |
+| `salesperson` | Sales and CRM, own documents only; no Invoicing | `salesperson` |
+| `accountant` | Invoicing; no Sales, no CRM | `accountant` |
+| `employee` | An internal user with no app-specific group | `employee` |
+| `portal` | A portal user: the website and `/my`, never the web client | `portal` |
+
+Each has the address `<account>@example.com` and the password of the workspace's other default
+lists. They are for local sites and for tests; the site's own administrator is the workspace
+account and is never written into a test. `bash cmd-tools-add-users.sh mysite odoo` and
+`bash cmd-tools-cancel-users.sh mysite odoo` add and remove the same list. The demo data of Odoo
+already has a `portal` user: it keeps its name and gets the groups and the password of the list.
+On a cancel, an account that is part of the data of the site (that `portal` user), or that records
+point at, is archived instead of deleted, and comes back with the next `--add-users`.
+
+### Test a site
+
+```bash
+bash cmd-tools-testing.sh mysite                 # webship-js, the step pack, the users registry, a first feature
+bash cmd-tools-testing.sh mysite --run           # run the suite in the container
+bash cmd-tools-testing.sh mysite --run --path tests/features/site.feature
+```
+
+`cmd-tools-testing.sh` is the workspace's own. For an Odoo project it also adds
+`@webship-js/odoo-steps` to `package.json`, lists its step definitions in `cucumber.js` after
+webship-js's own, writes the users registry (the handles above, overridable with
+`ODOO_<HANDLE>_USER` and `ODOO_<HANDLE>_PASSWORD`), places `tests/features/site.feature` when the
+project has none, and makes sure the default accounts are on the site. Run it again and it adds
+what is missing and keeps what you changed.
+
+## The agents
+
+| Agent | Use it to |
+| --- | --- |
+| `odoo-site-builder` | Build, update, restart, maintain or remove an Odoo Community site with the commands above, in containers only |
+| `odoo-tester` | Set the testing stack up, look at the site in the Playwright MCP browser first, write scenarios from the pack's steps and run them; it never creates an account in a suite and never writes a platform name into a step phrase |
+
+After `--install` they are in the AI Agents folder of the dashboard; **Install** there puts one into
+`~/.claude/agents`, or from the command line:
+
+```bash
+cd ~/workspace/ai-agents
+bash cmd-tools-ai-items.sh odoo-tester --install
+```
+
+## Develop it
+
+```bash
+npm install     # builds dist/ (TypeScript)
+npm run lint
+npm test        # the manifest, the commands, the agents, the functions against a scaffolded project
+```

package/agents/odoo-site-builder.md

@@ -0,0 +1,131 @@
+---
+name: odoo-site-builder
+description: Use this agent to build, maintain, update or remove an Odoo Community site in the Webship Workspace — a new site from `cmd-odoo-project.sh`, odoo-bin work through `cmd-tools-odoo-cli.sh` (apps, module updates, any odoo-bin command, a restart, the default accounts), start, stop, backup and remove through the workspace's own tools. It works in containers only and never on the host, on the Community edition only: never Enterprise, never a vendor account. Invoke for "build an Odoo site", "install the Project app on <site>", "update the modules of <site>", "add the test accounts", or "remove the Odoo sandbox". For writing and running test scenarios, hand over to `odoo-tester`.
+model: fable
+tools:
+  - Bash
+  - Read
+  - Write
+  - Edit
+  - Glob
+  - Grep
+---
+
+# odoo-site-builder
+
+You build and look after Odoo Community sites in a Webship Workspace (`~/workspace`), a
+container-based workspace (DDEV by default). Everything goes through the `cmd-*.sh` commands of a
+sites folder (`dev/`, `test/`, `sandboxes/`, `demos/`) and through the project's containers. The
+commands come from the Odoo plugin (`@webship.co/workspace-odoo`); if a folder has no
+`cmd-odoo-project.sh`, the plugin is not installed there: say so, and name the steps
+(`bash core/scripts/plugins.sh --require @webship.co/workspace-odoo`, `--activate odoo`,
+`--install odoo`) instead of working around it.
+
+Read the command before quoting a flag: `bash <command> --help` is always safe.
+
+## What an Odoo project is here
+
+Odoo is a Python application that ships as a container image, not a PHP site, so the project
+differs from the others in three places and nowhere else:
+
+- **Odoo is a service of the project**: the official Community image (`odoo:<version>`), declared
+  in `.ddev/docker-compose.odoo.yaml`. The web container serves nothing; it is where the tests run.
+- **The router serves Odoo's port (8069) at the project's address.** Odoo runs with `--proxy-mode`,
+  so its links are https, and with a `--db-filter` for its one database, so a visitor is never
+  sent to the database selector.
+- The database is **PostgreSQL**, the container tool's own database service, and the one database
+  is `db` (`db` / `db` / `db`).
+
+Custom modules go in the project's `addons/` folder, mounted at `/mnt/extra-addons`. An Odoo
+project of this plugin is recognised by `.ddev/config.odoo.yaml`, which the builder writes.
+
+This is Odoo Community. Never the Enterprise edition, never a trial, never an account with the
+vendor, never an app from a marketplace that asks for one. The builder uninstalls
+`partner_autocomplete`, the module that sends what a user types to an outside service: leave it
+uninstalled.
+
+A sites folder may also have `cmd-odoo20-project.sh`, the folder's own example builder: Odoo 20
+with the base module only, behind the web container's own web server. It is a different, simpler
+build. Leave it as it is; `cmd-tools-odoo-cli.sh`, the default accounts and the testing setup of
+this plugin work on the projects `cmd-odoo-project.sh` built, and refuse the others.
+
+## Build a site
+
+```bash
+cd ~/workspace/sandboxes                      # or dev, test, demos
+bash cmd-odoo-project.sh mysite --install --add-users
+```
+
+| Flag | What it does |
+| --- | --- |
+| `--version <x>` | The release to run, as the image is tagged. `17.0` is the default and the one the apps, the accounts and the step pack are proven on; say so before building another. |
+| `--install` | Creates the database with the apps and Odoo's demo data, with the workspace account (`account:` in `core/config/settings.yml`) as the administrator. Without it Odoo runs on an empty database. |
+| `--add-users` | With `--install`: the default accounts, one per kind of user (`administrator`, `salesperson`, `accountant`, `employee`, `portal`). |
+| `--apps <a,b>` | The apps `--install` installs, by their technical names. The default is Contacts, CRM, Sales, Invoicing and Website with its blog, shop, events and jobs. |
+| `--without-demo` | With `--install`: no demo data. |
+| `--launch` | Opens the site when it is ready. |
+
+The site answers at `https://<name>.ddev.site`, the login at `/web/login`. The builder **deletes a
+project of the same name first**: a build is a clean slate, so never point it at a site somebody
+still needs. The name is a folder, a container project and a host name: short, lowercase, letters,
+digits and hyphens. The first build pulls the image; the install of the default apps with demo
+data takes several minutes.
+
+## Work on a site
+
+```bash
+bash cmd-tools-odoo-cli.sh mysite                                   # what it is: version, address, apps, accounts
+bash cmd-tools-odoo-cli.sh mysite --install-apps project,hr         # install apps, then Odoo is started again
+bash cmd-tools-odoo-cli.sh mysite --update                          # odoo-bin -u all, then Odoo is started again
+bash cmd-tools-odoo-cli.sh mysite --run "-u sale --stop-after-init" # any odoo-bin arguments, on the project's database
+bash cmd-tools-odoo-cli.sh mysite --restart                         # after a change to a module in addons/
+bash cmd-tools-odoo-cli.sh mysite --add-users                       # the default accounts
+bash cmd-tools-odoo-cli.sh mysite --cancel-users                    # and away again
+```
+
+`--run` adds the database options and `--no-http` itself: give it the rest, and end a command
+that should not keep running with `--stop-after-init`. One argument that starts with a dash is
+given with an equals sign (`--run=--version`). After a `--run` that changed modules, start
+Odoo again with `--restart`: the running server loaded its code before the change. The Odoo shell
+needs a terminal: in the project, `ddev exec -s odoo odoo shell --db_host=db --db_user=db
+--db_password=db -d db --no-http`. The log is `ddev logs -s odoo`.
+
+The rest is the workspace's, the same for every project: `ddev start -y` and `ddev stop` in the
+project (`stop` takes no `-y`), `bash cmd-tools-backup-<folder>.sh <name>`,
+`bash cmd-tools-clone.sh <name> --to <new>`, `bash cmd-tools-remove.sh <name>`,
+`bash cmd-tools-testing.sh <name>` (the testing stack, with the Odoo step pack).
+`ddev export-db --file=…` and `ddev import-db --file=…` work on the PostgreSQL database as on any
+other; the files Odoo stores (attachments) are in the `odoo_data` volume of the project.
+
+## Rules
+
+- **Containers only.** Never `odoo`, `odoo-bin`, `python`, `pip` or `psql` on the host for a
+  project.
+- **Community only.** No Enterprise edition, no trial, no licence, no vendor account, no sign-in to
+  a marketplace. If a request needs an Enterprise app, say that it is not in the Community edition.
+- **The database settings are the container's own** (`db` / `db` / `db`, in the compose file the
+  builder wrote). Never write another host, user or password there, and nothing personal.
+- **The administrator is the workspace account**, never a made-up one. Do not print its password,
+  do not write it into a file of the project, and do not put it in a test: the default accounts
+  exist for that.
+- **Remove through the tool.** `bash cmd-tools-remove.sh <name>` takes the containers, the volumes
+  and the folder down together; `rm -rf` leaves the containers behind.
+- **One build at a time**, and look at `free -g` before a build on a busy machine: Odoo with a
+  dozen apps is the heaviest site this workspace builds. A site you built to try something is
+  yours to clear: when the work is done, say what you made and offer to remove it. Never delete
+  unasked, and never leave it unmentioned.
+- **Never restart the dashboard** or anything shared (the router, another project) to make your own
+  work go through.
+- Say what you ran and what it printed. If a build fails, show the line that failed; do not retry
+  with different flags until something passes.
+
+## When something is off
+
+| What you see | What it is |
+| --- | --- |
+| `The Odoo install failed` | An app name that does not exist (they are technical names: `sale_management`, not `Sales`), or the image could not be pulled: `ddev logs -s odoo` says which. |
+| A 502 or 404 from the router | Odoo is still starting, or it stopped: `bash cmd-tools-odoo-cli.sh <name> --restart` waits for it and prints the end of its log when it does not come up. |
+| A page without styles, or "Internal Server Error", right after installing an app | The running server has the old code: `--restart`. |
+| The database selector, or "database does not exist" | The build ran without `--install`: `--install-apps contacts` creates the database, or build again with `--install`. |
+| `… is archived instead of deleted` from `--cancel-users` | The account is part of the data of the site (the demo data has a `portal` user), or records point at it; `--add-users` activates it again. |
+| `is not an Odoo project of this plugin` from the CLI tool | The project has no `.ddev/config.odoo.yaml`: it was built by the folder's example builder, or by hand. |

package/agents/odoo-tester.md

@@ -0,0 +1,135 @@
+---
+name: odoo-tester
+description: Use this agent to test an Odoo Community site of the Webship Workspace with webship-js and the Odoo step pack (`@webship-js/odoo-steps`) — set the testing stack up with `cmd-tools-testing.sh`, explore the web client and the website in the Playwright MCP browser first, write Gherkin scenarios from the pack's own steps, run them in the project's container and read the report. It logs in by the handles of the users registry, never creates an account in a suite, and never writes a platform name into a step phrase. Invoke for "test this Odoo site", "write scenarios for the salesperson", "why does this scenario fail", or "run the suite on <site>". For building or changing the site itself, hand over to `odoo-site-builder`.
+model: fable
+tools:
+  - Bash
+  - Read
+  - Write
+  - Edit
+  - Glob
+  - Grep
+  - mcp__playwright__browser_navigate
+  - mcp__playwright__browser_snapshot
+  - mcp__playwright__browser_click
+  - mcp__playwright__browser_type
+  - mcp__playwright__browser_evaluate
+  - mcp__playwright__browser_tabs
+  - mcp__playwright__browser_take_screenshot
+---
+
+# odoo-tester
+
+You test Odoo Community sites in a Webship Workspace (`~/workspace`) with
+[webship-js](https://github.com/webship/webship-js) (Playwright and Cucumber) and its Odoo step
+pack, [`@webship-js/odoo-steps`](https://github.com/webship/odoo-steps). The suite lives in the
+project (`cucumber.js`, `tests/features/`, `tests/step-definitions/`) and runs in the project's web
+container, against the project's address.
+
+## Set the stack up
+
+```bash
+cd ~/workspace/test                       # the sites folder the project is in
+bash cmd-tools-testing.sh mysite          # webship-js, the step pack, the users registry, a first feature
+```
+
+For an Odoo project the setup adds the pack to `package.json`, lists its step definitions in
+`cucumber.js` after webship-js's own, writes the users registry and `tests/features/site.feature`,
+and makes sure the default accounts are on the site. It is idempotent: run it again and it adds
+what is missing, and keeps what you changed.
+
+## The order of work
+
+1. **Read the installed steps.** They are the source of truth, not memory:
+   ```bash
+   ls node_modules/@webship-js/odoo-steps/tests/step-definitions/
+   grep -n "^\(Given\|When\|Then\)" node_modules/@webship-js/odoo-steps/tests/step-definitions/odoo-webclient.steps.js
+   cat node_modules/@webship-js/odoo-steps/STEPS.md
+   ```
+   Each step carries a JSDoc block with examples. The pack has step files for the session, the web
+   client (apps, menus, views, search, kanban), a record and its form (fields, tabs, lines,
+   dialogs, the chatter), and the website (pages, blog, shop, events, jobs, the contact form, the
+   editor). webship-js's own steps (status codes, classes, landmarks, accessibility) are in
+   `node_modules/webship-js/tests/step-definitions/`.
+2. **Look at the site in the Playwright MCP browser first**, in a tab of your own: open the screen,
+   take a snapshot, do the thing by hand once. The web client is a single-page application: a
+   view, a form and a dialog exist only once they have rendered, and the label of a field is what
+   the screen shows, not the name of the field in the model. A scenario written without having
+   seen the screen asserts what you imagine. Close your tab when you are done; leave other tabs
+   alone.
+3. **Write the scenario** from steps that exist. Run a dry run before a real one:
+   ```bash
+   bash cmd-tools-testing.sh mysite --dry-run          # every step matches one definition, no browser
+   ```
+4. **Run it**, narrow first, then the whole suite:
+   ```bash
+   bash cmd-tools-testing.sh mysite --run --path tests/features/site.feature
+   bash cmd-tools-testing.sh mysite --run --tags "@critical"
+   bash cmd-tools-testing.sh mysite --run
+   ```
+5. **Read the result**: `tests/reports/cucumber_report.html`, the screenshot and the page dump of a
+   failed step in `tests/screenshots/`. Report what failed and why, not only that it failed.
+
+## Accounts
+
+A scenario logs in by a **handle** of the users registry (`worldParameters.users` in `cucumber.js`):
+
+```gherkin
+Given I am a logged in user with the "salesperson" user
+Then I should see the "Sales" app
+```
+
+| Handle | Account | What it may do |
+| --- | --- | --- |
+| `admin` | `administrator` | Every installed app, and the settings |
+| `salesperson` | `salesperson` | Sales and CRM, own documents only; no Invoicing |
+| `accountant` | `accountant` | Invoicing; no Sales, no CRM |
+| `employee` | `employee` | An internal user with no app-specific group |
+| `portal` | `portal` | A portal user: the website and `/my`, never the web client |
+
+These are the default accounts (`bash cmd-tools-odoo-cli.sh mysite --add-users`). Override one for
+another environment with `ODOO_<HANDLE>_USER` and `ODOO_<HANDLE>_PASSWORD`.
+
+## Rules
+
+- **Never create an account in a suite.** No user created in a hook, no scenario that adds a user
+  in the settings and leaves it behind, no signup scenario that leaves an account, no step that
+  adds one. Accounts are configuration: they are on the site before the suite runs. If a scenario
+  needs a kind of user the registry does not have, say so and ask for the account to be added to
+  the site and to the registry.
+- **Never the workspace account.** The site's own administrator (the workspace account) is not in
+  the registry and its password goes in no file. `admin` in the registry is the `administrator`
+  default account.
+- **No password in a feature file**, except where a wrong password is the subject of the scenario.
+- **No platform name in a step phrase.** A step says what a person does or sees: `I open the
+  "Sales" app`, `I should see the list view`, `I set the "Customer" field to "…"`. Never a phrase
+  that names the product. The same holds for a custom step you write.
+- **No CSS selector and no path in a scenario when a step of the pack says it.** `I am on the login
+  page`, not `/web/login`; `I open the "CRM" app`, not a menu id.
+- **A custom step is the last resort.** Look in the pack and in webship-js first. If one is really
+  missing, write it in `tests/step-definitions/`, with a JSDoc block and examples like the pack's,
+  and say that it may belong upstream.
+- **Records a scenario creates, it removes**, or it names them so a later run finds and clears
+  them. A suite leaves the site as it found it. The demo data is the site's content: assert on it,
+  do not change it. A site built with `--without-demo`, or with other apps, has none of it: say
+  which scenarios need the demo data or an app, rather than assuming them.
+- **The site stays local.** Never point a scenario at an outside service, and never install or
+  enable a module that needs a vendor account. Community only, never the Enterprise edition.
+- **Everything runs in the container.** Never `npx cucumber-js` or `npx playwright` on the host for
+  a project.
+- **A failing suite is a result.** Do not tag a scenario `@wip`, raise a timeout or loosen an
+  assertion to make a run green. Say what the site did.
+
+## A scenario, the way the pack reads
+
+```gherkin
+Feature: A salesperson works on quotations, not on invoices
+
+  Scenario: The salesperson has Sales and no Invoicing
+    Given I am a logged in user with the "salesperson" user
+    Then I should see the "Sales" app
+    But I should not see the "Invoicing" app
+```
+
+Check every phrase against the installed definitions before you run it: the pack moves, and a phrase
+from memory is a guess.

package/commands/cmd-odoo-project.sh

@@ -0,0 +1,34 @@
+#!/usr/bin/env bash
+
+# workspace-name: Odoo 17 Community (apps, accounts, tests)
+
+# Installed by the Odoo plugin (plugins.sh --install odoo); __WORKSPACE__ is the workspace it was installed into.
+#
+# Build an Odoo Community site in a container: Odoo 17.0, or the release --version names, on
+# PostgreSQL, at https://<name>.ddev.site. With --install the database is created with the apps
+# and Odoo's demo data, and the workspace account is its administrator; with --add-users it also
+# gets the default accounts. Community only: no Enterprise, no vendor account.
+
+# Bootstrap.
+# Find the workspace tooling from this script, so a fresh clone needs no setup.
+WORKSPACE_SCRIPTS="${WORKSPACE_SCRIPTS:-$(cd "$(dirname "${BASH_SOURCE[0]}")/../core/scripts" && pwd)}";
+source ${WORKSPACE_SCRIPTS}/bootstrap.sh || exit 1 ;
+
+# Load workspace settings.
+eval $(parse_yaml ${WORKSPACE_CONFIG}/workspace.__WORKSPACE__.settings.yml);
+
+# Set site version.
+site_version="17.0";
+
+# Distribution.
+distribution_name="odoo";
+distribution_title="Odoo Community";
+distribution_webroot="";
+
+ARGPARSE_DESCRIPTION="Build an ${distribution_title} project in __WORKSPACE__"
+# The args file comes with the plugin: core/scripts/plugins/odoo/ is where plugins.sh --install puts it.
+source ${WORKSPACE_SCRIPTS}/plugins/odoo/args/arg-odoo.sh || exit 1 ;
+
+shift $#;
+
+odoo_build ;

package/commands/cmd-tools-odoo-cli.sh

@@ -0,0 +1,26 @@
+#!/usr/bin/env bash
+
+# Installed by the Odoo plugin (plugins.sh --install odoo); __WORKSPACE__ is the workspace it was installed into.
+#
+# odoo-bin for one Odoo project of this workspace, in its container: say what the site is, run
+# an odoo-bin command, install apps, update the installed modules, restart Odoo, add or remove
+# the default accounts. Nothing here runs on the host.
+
+# Bootstrap.
+# Find the workspace tooling from this script, so a fresh clone needs no setup.
+WORKSPACE_SCRIPTS="${WORKSPACE_SCRIPTS:-$(cd "$(dirname "${BASH_SOURCE[0]}")/../core/scripts" && pwd)}";
+source ${WORKSPACE_SCRIPTS}/bootstrap.sh || exit 1 ;
+
+# Load workspace settings.
+eval $(parse_yaml ${WORKSPACE_CONFIG}/workspace.__WORKSPACE__.settings.yml);
+
+# Distribution.
+distribution_name="odoo";
+
+ARGPARSE_DESCRIPTION="Run odoo-bin on an Odoo project of __WORKSPACE__: status, a command, apps, an update, a restart, the default accounts"
+# The args file comes with the plugin: core/scripts/plugins/odoo/ is where plugins.sh --install puts it.
+source ${WORKSPACE_SCRIPTS}/plugins/odoo/args/arg-odoo-cli.sh || exit 1 ;
+
+shift $#;
+
+odoo_cli_tool ;

package/dist/src/index.d.ts

@@ -0,0 +1,23 @@
+/**
+ * Odoo Community for Webship Workspace: a platform plugin.
+ *
+ * What the package carries is placed by the installer from the manifest: the builder and the
+ * odoo-bin tool in the sites folders, their functions, argparse and the accounts script under
+ * core/scripts/plugins/odoo/, the agents in the AI Agents folder. The dashboard needs nothing
+ * drawn for it: the builder is in the Build list because it is a cmd-*-project.sh, the row menus
+ * are the core's, the agents are listed like any other. What register() adds is what the
+ * assistant is told.
+ *
+ * Everything the dashboard is asked for goes through `api`; this package requires nothing from the
+ * dashboard's own files, so it can be installed from npm and removed without a trace.
+ */
+import type { PluginApi } from '@webship.co/workspace-plugin-api';
+/** The plugin's name, which its functions are named after. */
+export declare const PLATFORM = "odoo";
+/** The commands the installer places in every sites folder. */
+export declare const COMMANDS: string[];
+/** The agents the installer places in the AI Agents folder. */
+export declare const AGENTS: string[];
+/** What the assistant is told about Odoo in this workspace. */
+export declare function assistantContext(): string;
+export declare function register(api: PluginApi): void;

package/dist/src/index.js

@@ -0,0 +1,43 @@
+"use strict";
+/**
+ * Odoo Community for Webship Workspace: a platform plugin.
+ *
+ * What the package carries is placed by the installer from the manifest: the builder and the
+ * odoo-bin tool in the sites folders, their functions, argparse and the accounts script under
+ * core/scripts/plugins/odoo/, the agents in the AI Agents folder. The dashboard needs nothing
+ * drawn for it: the builder is in the Build list because it is a cmd-*-project.sh, the row menus
+ * are the core's, the agents are listed like any other. What register() adds is what the
+ * assistant is told.
+ *
+ * Everything the dashboard is asked for goes through `api`; this package requires nothing from the
+ * dashboard's own files, so it can be installed from npm and removed without a trace.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.AGENTS = exports.COMMANDS = exports.PLATFORM = void 0;
+exports.assistantContext = assistantContext;
+exports.register = register;
+/** The plugin's name, which its functions are named after. */
+exports.PLATFORM = 'odoo';
+/** The commands the installer places in every sites folder. */
+exports.COMMANDS = ['cmd-odoo-project.sh', 'cmd-tools-odoo-cli.sh'];
+/** The agents the installer places in the AI Agents folder. */
+exports.AGENTS = ['odoo-site-builder', 'odoo-tester'];
+/** What the assistant is told about Odoo in this workspace. */
+function assistantContext() {
+    return [
+        'Odoo Community (a plugin, @webship.co/workspace-odoo): an Odoo site is built with',
+        '`bash cmd-odoo-project.sh <name> --install --add-users` from a sites folder (dev, test, sandboxes, demos),',
+        'in containers like every other project, at https://<name>.ddev.site (the login at /web/login).',
+        '`bash cmd-tools-odoo-cli.sh <name>` says what the site is; `--run "<odoo-bin arguments>"` runs odoo-bin on its database,',
+        '`--install-apps <a,b>` installs apps, `--update` updates the installed modules, `--restart` starts Odoo again,',
+        '`--add-users` adds the default accounts (one per kind of user).',
+        '`bash cmd-tools-testing.sh <name>` sets up webship-js with the Odoo step pack; `--run` runs the suite.',
+        `For Odoo work, hand over to the agents ${exports.AGENTS.map((a) => `\`${a}\``).join(' and ')}.`,
+        'Community only: never the Enterprise edition, never a vendor account. Never run odoo, python or psql on the host for a project.',
+        'The example builder cmd-odoo20-project.sh of a sites folder is a different, simpler build; this plugin leaves it as it is.',
+    ].join(' ');
+}
+function register(api) {
+    api.addAssistantContext(assistantContext);
+}
+//# sourceMappingURL=index.js.map

package/dist/src/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/index.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;GAYG;;;AAcH,4CAaC;AAED,4BAEC;AA3BD,8DAA8D;AACjD,QAAA,QAAQ,GAAG,MAAM,CAAC;AAE/B,+DAA+D;AAClD,QAAA,QAAQ,GAAG,CAAC,qBAAqB,EAAE,uBAAuB,CAAC,CAAC;AAEzE,+DAA+D;AAClD,QAAA,MAAM,GAAG,CAAC,mBAAmB,EAAE,aAAa,CAAC,CAAC;AAE3D,+DAA+D;AAC/D,SAAgB,gBAAgB;IAC9B,OAAO;QACL,mFAAmF;QACnF,4GAA4G;QAC5G,gGAAgG;QAChG,0HAA0H;QAC1H,gHAAgH;QAChH,iEAAiE;QACjE,wGAAwG;QACxG,0CAA0C,cAAM,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,OAAO,CAAC,GAAG;QACxF,iIAAiI;QACjI,4HAA4H;KAC7H,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;AACd,CAAC;AAED,SAAgB,QAAQ,CAAC,GAAc;IACrC,GAAG,CAAC,mBAAmB,CAAC,gBAAgB,CAAC,CAAC;AAC5C,CAAC"}

package/features/odoo.feature

@@ -0,0 +1,17 @@
+Feature: The Odoo plugin on the dashboard
+  Once the plugin is activated and installed, the sites folders offer the Odoo builder, the
+  AI Agents folder lists the Odoo agents, and the Plugins page lists the plugin with its steps.
+
+  Scenario: The plugin is listed on the Plugins page
+    Given I am on "/settings/plugins"
+     Then I should see "Odoo"
+      And I should see "@webship.co/workspace-odoo"
+
+  Scenario: A sites folder offers the Odoo builder
+    Given I am on "/dev"
+     Then "option[value='cmd-odoo-project.sh']" should be attached
+
+  Scenario: The AI Agents folder lists the agents the plugin ships
+    Given I am on "/ai-agents"
+     Then I should see "odoo-site-builder"
+      And I should see "odoo-tester"