Generated-Only

When To Use

Use this archetype when the adapter has no real transport layer yet, or when behavior can be modeled entirely inside framework Things, command handlers, and background services.

Typical fit:

• simulator adapters
• demo adapters
• framework capability exploration
• command and function behavior prototyping

Core Shape

• source-generated startup
• adapter-registration.yaml
• no custom transport implementation
• one or more IDeviceConnection Things that connect immediately
• command handlers drive function methods directly
• optional background services for simulation or orchestration

Typical Files

• Pq.Adapter.<Name>.csproj
• adapter-registration.yaml
• Devices/<RootThing>.cs
• Commands/*.cs
• optional AdapterRegistrations.cs
• optional StatusPolling.cs

Minimal Flow

command -> generated dispatcher -> command handler -> Thing function method -> PQ event/status

Minimal Pseudocode

public partial class DemoPanel : IDeviceConnection
{
    public Task<bool> Connect(ConnectionContext context, CancellationToken ct)
        => Task.FromResult(true);

    public Task Disconnect(CancellationToken ct)
        => Task.CompletedTask;
}

public static class DoorCommands
{
    public static Task<DeviceCommandResult> Open(
        DemoDoor door,
        Access.Open command,
        CancellationToken ct) =>
        door.ExecuteCommand(
            DoorState.Unsecured,
            send: () => Task.FromResult(true),
            onSuccess: async () => await door.UnsecuredRemote(DeviceTimestamp.UtcNow),
            ct: ct);
}

Common Pitfalls

• adding custom transport code when simple IDeviceConnection is enough
• introducing unnecessary local state instead of using framework function state
• forgetting that generated startup already exists after build
• making the example too synthetic to teach real command/function patterns

Good First Deliverable

Implement one root Thing, one child Thing, one command handler, and one end-to-end event-producing action.