Lab #620: Inconsistent resource-field accessor: data get returns content, data query and CEL use attributes

Description

The same resource's fields are addressed under different top-level keys depending on the command, with no alias, so applying the accessor learned from one command to the other silently yields nulls:

swamp data get <model> <spec> --json -> fields live under the top-level content key.
swamp data query '<pred>' --select '{ x: attributes.<field> }' and CEL expressions -> fields live under attributes.

Steps to reproduce

Any model that writes a resource with, say, a field foo.
swamp data get <model> <spec> --json returns { ..., "content": { "foo": ... } } — note the wrapper key is content.
swamp data query 'modelName == "<model>" && specName == "<spec>"' --select '{ "foo": attributes.foo }' works only via attributes.foo.
Using attributes.foo against the data get --json output (or content.foo in a --select) returns null with no error.

Expected

One consistent accessor for resource fields across data get, data query --select, and CEL — or at least an attributes alias exposed on data get --json (and/or content honored in --select), so the two are interchangeable.

Actual

data get exposes fields under content; data query / CEL use attributes. Mixing them produces silent nulls, costing a debugging round-trip.

Suggested fix

Alias the two (expose attributes on data get --json, or accept content in --select/CEL), or document the distinction prominently in both the swamp data get and swamp data query help and the data skill.

Environment

swamp 20260608.234005.0-sha.ed5f78a4.

extension push: issue-verdict review is indistinguishable from missing/stale

Document model-method data-mutation surface (dataRepository.delete, findAllForModelSince, queryData)

@swamp/aws/cloudformation: expose StackSet instances, drift, and operations (Cloud Control cannot)

extension push: adversarial-review report hash is platform-dependent (macOS vs Linux), so committed reviews never match a cross-OS runner

model search --json returns a bare model object instead of {query, results} when exactly one model matches

model delete --json output shape doesn't match the documented {deleted, modelId, modelName, artifactsDeleted}

Extension API: allow export const extension to add resource specs, or document that it cannot

Add a way to list registered report definitions (report search only lists results)

workflow validate: method args with a Zod .default() are treated as required

Inconsistent resource-field accessor: data get returns content, data query and CEL use attributes

extension quality scorer mis-detects quoted phrases in comments as bare imports

Support CI-friendly adversarial review artifacts for extension push

extension push --dry-run --json reports local helper imports as bogus model entries

Extension source: direct-content export scan only reads first 64 KiB, silently drops exports beyond it

Managed skills ship with dangling reference-doc links

Add a list/discover method to dbcluster for enumerating clusters in a region

workflow-scope report's dataRepository.getContent returns null for data written in the same workflow run

dbcluster state schema is missing DBClusterMembers (writer/reader, instance class)

workflow direct-execution inputs.* persist as globalArguments on auto-definitions and freeze on first run

Workflow validation should resolve modelType for direct-execution steps

bucket-policy StateSchema.PolicyDocument declared z.string() but CloudControl returns it as a parsed object

bucket-policy GlobalArgsSchema requires Bucket and PolicyDocument, blocking workflow-YAML direct execution of get

Report execute throws are advisory: workflow marked succeeded, exit 0, AND report output is discarded

dataRepository.getContent rejects string type in production but docs and testing helper demonstrate strings

Relationships

#620 Inconsistent resource-field accessor: data get returns content, data query and CEL use attributes