# Features Compatibility Notes

`features` is legacy organization-model wording. Current Organization OS vocabulary is
System/Action oriented:

- **Systems** describe availability, routing, ownership, navigation grouping, and knowledge
  mounts.
- **Actions** describe invokable operations such as workflows, agents, commands, and UI-triggered
  tasks.

Use this file only when older prompts, browser copy text, SDK references, or scaffold recipes still
say "feature". For current tenant organization-model work, route the user to Systems and Actions
wording and use `/by-system/<id>` knowledge paths.

## Compatibility Mapping

| Legacy wording                                                                        | Current wording                                 |
| ------------------------------------------------------------------------------------- | ----------------------------------------------- |
| Feature toggle                                                                        | System availability or routing toggle           |
| Feature ID                                                                            | System ID when discussing Organization OS       |
| Add a custom feature                                                                  | Add or extend a System, then define any Actions |
| Feature governs X                                                                     | System governs X                                |
| `/om read-folder feature:x` (legacy `/knowledge read-folder feature:x` also accepted) | `/om read-folder system:x`                      |
| `/by-feature/x`                                                                       | `/by-system/x`                                  |

`by-feature` may still exist as a legacy compatibility axis in older tools. Do not introduce new
guidance that depends on it; prefer `by-system` everywhere.

## What To Do With Toggle Requests

For natural-language requests like "turn on lead gen", "disable SEO", or "enable CRM":

1. Treat the request as a System availability/routing change.
2. Read the Systems config file to find the matching System entry or platform default constant
   exposed by `@elevasis/core/organization-model`. For split projects this is
   `core/config/organization-model/systems.ts`; for unsplit projects use
   `core/config/organization-model.ts`.
3. Propose the exact availability/routing change in plain language.
4. After confirmation, run the Level A codify ceremony in `operations/codify-level-a.md`, passing
   `targetFile` as `core/config/organization-model/systems.ts` (split) or
   `core/config/organization-model.ts` (unsplit).

Do not create new extension files for a simple on/off change.

## When Level B Applies

Level B applies only when the user explicitly asks for a new structural concept that cannot be
represented as an existing System or Action configuration. In current vocabulary this usually
means adding a project-owned extension under `core/config/extensions/` and wiring it into the
organization model.

Older references may call this "adding a custom feature"; translate it to "add or extend a
System and define any Actions it owns" before invoking `operations/codify-level-b.md`.

## UI Package Exception

Keep the word `features` only for legacy frontend source paths that still use that directory
name, such as `ui/src/features/`. Current published shell APIs are System-oriented:
`SystemShell`, `SystemModule`, and `ElevasisSystemsProvider`.

## Read Examples

Use current system paths:

```bash
pnpm exec elevasis-sdk om:ls /by-system/<id> --ids-only
pnpm exec elevasis-sdk om:cat <node-id>
```

Legacy browser output (the `/knowledge` slash form is preserved as a permanent alias for `/om`):

```text
/knowledge read-folder feature:<id>
/om read-folder feature:<id>
```

Resolve as:

```bash
pnpm exec elevasis-sdk om:ls /by-system/<id> --ids-only
```
