# LongField Developer and Customization Guide

**Status:** General guidance. The exact source/configuration inventory, framework versions, build steps, extension points, and migration instructions will be identified in the verified release package.

## Before changing the licensed copy

Read the [architecture overview](architecture.html), [system requirements](system-requirements.html), [license](../legal/software-license-v1.0.html), and release notes. Inspect the source and configuration before editing. Make a reversible branch or copy, keep an untouched recovery point, and document each change.

## Preserve operational boundaries

LongField organizes legal operations around matter context. Changes should preserve firm/workspace scoping, role permissions, matter relationships, audit history, and existing database migrations. Do not assume a screen-level restriction protects server-side records. Review authorization at the data and action boundaries.

## Safe implementation practice

- Identify affected records, permissions, integrations, and migration behavior before editing.
- Do not modify production data to test a code change.
- Keep schema changes incremental and provide a tested rollback or recovery procedure.
- Use fictional sample records for public demonstrations.
- Test representative matter relationships, document access, deadlines, billing state, and cross-workspace restrictions.
- Keep customer-specific changes separate from reusable Coal Road product components where the applicable agreement requires it.

Customers may use their own staff, contractors, editors, and development tools subject to the final license and third-party obligations. See the [AI-assisted development guide](ai-development-guide.html).

## Working on the code manually

AI tools are optional. You can work with the included guides using your own editor, IDE, internal development team, contractor, or command-line workflow.

1. Locate the source and read the [architecture overview](architecture.html), [system requirements](system-requirements.html), license, and release notes.
2. Create a protected backup or version-control checkpoint before editing.
3. Inspect the affected routes, data models, permissions, storage behavior, and existing migrations.
4. Make a scoped change and document its purpose and affected boundaries.
5. Run the checks and tests listed for that exact release; review every migration and its recovery path.
6. Stage the change with fictional test records. Verify firm/workspace permissions, document access, secrets, and filesystem ownership.
7. Deploy deliberately only after review, backup, and an approved release procedure.

The packaged release must supply its exact source inventory, dependency lock, and tested build commands. Where they are absent, verify the procedure against the release-specific installation notes rather than guessing.