# Working on Lily

Lily is the Support family's ticket desk edition for one business. A ticket is a
visible case with customer messages on its linked conversation; the default
creates one hidden conversation per ticket, without a separately browsable
conversation inventory. Preserve that product intent and its ticket lifecycle.
The current public-request and reviewed SendGrid reply pilot covers only part of
the intended 1.0 contract. Provider acceptance is distinct from delivery.

This repository is authoritative for Lily's complete product source and component selection. Maintainers, owners and community publishers author here through the same workflow. Its purpose,
implemented scope and operating instructions are in `README.md`; current coverage
and remaining work are in `HANDOVER.md`. Read those documents, `CONTRACT.md`,
`BASELINE.md`, `seed.json`, and existing customisations before changing behaviour.
Read `DIVERGENCE.md`, owner instructions and `.seed/intent.md` where present.
Owner requirements are binding regardless of their document format; no intent
file is required.

## Run Lily

Use the pinned pnpm version in `package.json`. The installed commands include:

```sh
pnpm install --frozen-lockfile
pnpm run dev
pnpm run verify
```

For provisioning and deployment, follow [the pilot guide](docs/SUPPORT-PILOT.md)
and [README.md](README.md), including origin, native owner sign-in, mail and
resource configuration. Run `pnpm run setup -- --dry-run` to inspect provisioning
and `pnpm run deploy -- --dry-run` for the local rehearsal before an authorised
`pnpm run deploy`. Use `pnpm run setup`, not pnpm's reserved shell-setup command.
These scripts do not establish branch-triggered deployment or PR previews.
Lily currently has no package export/import scripts; do not promise them.

## Make it fit

The owner may edit all source, including base code, family domain, modules,
application UI, configuration and tests for new owner requirements. This is a
complete repository; authoring repositories are not runtime services it needs.
Choose the coherent change that minimises total work, cost, elapsed time and
owner attention, including future verification and updates.

Use existing configuration or extension APIs where they help. Core changes are
fully legitimate. Adding or removing capabilities requires handling their data,
dependencies and integrated journeys explicitly. Keep files small, remove dead
code, and preserve server-side authorisation and secret boundaries. Access data
through the product's repository layer and validate inputs at trust boundaries.
Declare new externals and isolate their integration. Preserve already-applied
migration history; add migrations for core or extension schema changes and a
recovery path for destructive changes. Local and deployment commands apply
`migrations/core/` followed by owner SQL in `migrations/ext/`, with a separate
`lily_ext_migrations` ledger in the same database. See `migrations/README.md`.

Record why an intentional departure exists in the relevant requirement or divergence
record, with meaningful verification of the required behaviour. Do not silently
weaken a guarantee or change a test to hide a regression. When the owner changes
a requirement, record its replacement and verify it directly; describe any
unsupported override tooling honestly. Ordinary source edits need no separate
approval simply because they touch core code or lack an extension hook.

Preserve owner intent throughout ordinary Git updates, including changes in
`src/ext/`, `.seed/`, `migrations/ext/`, `tests/local/` and shared source.
No path restriction limits where the owner may edit.

## Verify and update

Run the edition's documented verification and exercise the affected journeys on
the real local app or a preview. Report uncovered or failing guarantees plainly.
A clean build or passing upstream tests alone does not prove owner intent survived.
No production mocks, hidden failures or semantic fallbacks.

Read the release changes, provenance and recorded intent before updating. Prepare
a candidate away from the live installation. Use update tooling only when the
edition supplies it; choose merge, rebase, reapplication or rewriting as appropriate.
Never regenerate over the owner's fork or discard conflicting work wholesale.
Verify applicable product guarantees, declared overrides and local intent tests
before adoption. Record what changed, what passed and any remaining limitation.

The owner may keep and change the MIT source independently of management services.
Use documented, verified export and restore procedures for data portability;
do not promise a command or recovery capability that has not been implemented.

## Recommended defaults and shared improvements

The maintained edition defaults save integration and verification work. Configuration
and hooks are conveniences; editing domain internals, core schema, UI, framework
or infrastructure is ordinary authoring too. Choose the change that serves the
owner's outcome, without a required sequence of extension mechanisms. Complex
merges and adaptation are the agent's work. Preserve the owner's actual requirements
wherever recorded: `CONTRACT.md`, `DIVERGENCE.md`, owner instructions and optional
`.seed/intent.md`; no particular intent file or registry is required.

Feed useful mechanisms, defaults and verification cases back into shared source
when they would save work in another edition. Their natural home may be this
edition, a family, Base or an independent repository; no separate repository per
module or universal compatibility interface is required. Verify adoption against
the receiving product's requirements, including deliberate local differences.