Create development data

Development fixtures are explicitly selected by the developer; they are not mandatory installation defaults. Start with Workshop from Create an App package and an active development sandbox.

Prepare a Resource

Run this in the App folder. Do not regenerate an existing Resource with the same name.

Code example

Shell

nexia make resource Example --record-owner tenant --label-ko 예제1

This Resource is tenant-owned. The current sandbox fixture context supplies empty legalEntities() and subjects() lists. Do not invent a default legal entity, create accounts, or copy production database records. Organization-owned fixtures need explicit App-supported organization resolution and authorization.

Declare the fixture

Create src/Contribution/WorkshopFixtures.php. Substitute the namespace, App key and model for another App. The generated Manifest already discovers this directory. One fixture contribution per App can handle multiple keys.

Code example

PHP

<?php

declare(strict_types=1);

namespace Nexia\Apps\Acme\Workshop\Contribution;

use InvalidArgumentException;
use Nexia\Apps\Acme\Workshop\Models\Example;
use Nexia\Fixture\Contracts\FixtureContribution;
use Nexia\Fixture\FixtureContext;

final class WorkshopFixtures implements FixtureContribution
{
    public function appKey(): string { return 'workshop'; }

    public function fixtureKeys(): array { return ['sample']; }

    public function seed(FixtureContext $context): void
    {
        if ($context->fixtureKey !== 'sample') {
            throw new InvalidArgumentException('Unsupported fixture.');
        }
        Example::firstOrCreate(
            ['name' => 'Sample example'],
        );
    }
}123456789101112131415161718192021222324252627

The model generates IDs and public UUIDs. This example matches by name, so renaming a sample permits another sample on the next run. Use an App-owned unique code if identity must survive name edits. The platform restores the actor in FixtureContext; App code does not supply tokens or database credentials. Use synthetic records without customer data or secrets.

Check fixture permissions

With the matching Core and Manager runtime update, fixtures can use PermissionAuthorizer::allowsPermission() and legalEntityKeysForPermission() for their own App, including legal-entity-scoped protected permissions. The platform restores the verified execution actor; use ActorDirectory with FixtureContext::actorUserId to obtain that actor. Grant the required permissions before seeding. Decisions use current grants, so revoked or expired access is denied. AuthorizationContext::run() selects a target; it does not grant access. Keep App record policies and rollback on denial.

Deploy Core before the compatible Manager runtime image, then prepare the development execution again before retrying the fixture. No new SDK API or CLI option is required. The reported fixture authorization issue tracks adoption; this documentation alone does not establish deployment.

With this Core fix, a new CLI fixture run can reach ordinary Gate permission checks without failing with HTTP 409 before authorization. Existing permissions still apply; do not bypass policies or reset data. When the compatible fixture runtime is already installed, no App or CLI update is required. After the Core fix is applied, inspect the previous result and explicitly retry only the intended fixture. See issue #24.

Verify fixture data

Wait for nexia dev to synchronize the Resource and fixture and finish preparation.
Stop the watcher with Ctrl+C. Run in the App folder:

Code example

Shell

nexia db seed sample
nexia db status12

Wait for completed, then restart nexia dev.
In workspace Settings → Credentials and access, place Example read/update permissions in a role and assign it to your user. Confirm the App's Examples list contains one record.
Repeat this procedure and confirm samples with the same name are not duplicated.

Accepted or queued is not completed. If the key is missing, check contribution discovery, appKey() and the prepared source revision. Fix the reported source error and rerun without administrator approval. Query the request ID first when the outcome is uncertain. This recipe is source-backed; verify its actual execution in your App separately.

Separate mandatory defaults

Use Required installation content for codes or defaults required for the first business operation. Keep sample records out of initializers. Local test fixtures in Test an App are also separate from retained remote sandbox data.

See the public CLI documentation for command and option details.

Diagnose a failed seed

If nexia db seed <key> --app <app-key> fails, inspect the step, source location and exception in the CLI or the Console operation details. The seed step runs the fixture after runtime preparation. Correct its prerequisite data or fixture code, then explicitly rerun the command. Do not reset the database or remove migration history. If transport was interrupted, recover the result with the original request ID before retrying; write fixtures to tolerate repeated execution without duplicates.

When saving code

Compatible development environments keep the same execution and DB connection across PHP source saves. Rejected changes retain the previous code, and screens refresh while preserving form input. Adopt Core 0.8.156, the compatible runtime from Manager 0.1.0-alpha.77, and CLI 0.2.0-alpha.43 together. Existing environments need preparation with a compatible runtime. Run migrations and seeders explicitly with nexia db. CLI 0.2.0-alpha.43 release notes · Change PR #166 · Update sources in the existing development execution