SKILL.md v2 compliance
Organisation Identity Write
Resolve a saved organisation via Ploutonion organization-identity and write identity.json.
No reviews yet 0 installs
suppliersidentitya2aploutonionwriteresource-action
Versions
- v2 # Changelog ## v7 - `inputs_from_record` now prefers `record.name` / `properties.name` over `record.resolvedName` / `properties.resolvedName` (matching `SKILL.md`) so a stale `resolvedName` cached on `resource.json` from an earlier resolution does not override the record's own name on subsequent runs. ## v6 - Updated `SKILL.md` (`primaryMarkdown`) after promotion from an embedded skill so `listingBundleFingerprint` differs from the prior embedded Cortex bundle and Curator mints and publishes a `community.listing_versions` row for the top-level skill listing. ## v5 - Promoted from a blueprint-local skill inside `organisation-identity` to a shared publisher skill under `assets/publishers/qonstrue/skills/organisation-identity-write` so both `organisation-identity` and `run-organisation-due-diligence` can reference it. ## v4 - Renamed from `supplier-identity-write` to `organisation-identity-write`, moving with its blueprint's rename to `organisation-identity`. No behaviour change: the cortex write path and `collection_root_for_slug` derivation are unchanged. ## v3 - Writes `identity.json` under the cortex collection the record's own resource type maps to: `ORGANIZATION_ROOT` joined with `collection_root_for_slug(resourceTypeSlug)`, rather than the previous hardcoded `SUPPLIERS_ROOT`. `supplier` aliases to `suppliers`, so a supplier record's path is byte-for-byte unchanged; a customer record's artefacts would now land under `/organization/local/customer/{id}/`. - The write-path keyword is renamed `suppliers_root` → `collection_root`, matching the reader skills' existing name for the same concept. - Blueprint-side only: the marketplace writers (`partnerIdentitySourceBuilder`, `cortexProfile`) remain supplier-rooted, so customer records still have no upstream provisioning path. This change alone does not make customers work. ## v2 - Reads the record from `{collection_root}/{resource_id}/resource.json` on the cortex mount when the blueprint passes `--resource-id` (now wired into the CLI, matching `supplier-ownership-write` and `supplier-financials-write`) — `qb.get_resource` (Postgres) is no longer consulted on that path. A missing or unreadable `resource.json` fails the run explicitly rather than silently falling back. - Best-effort writes the resolved identity back onto the record's own `properties`: `resolvedName` always, `companyNumber` fill-only (a record already holding `2347327` keeps it even when the resolve returns `05001590`, a different company — correcting it is a data decision), and `name` never touched. Reported under `recordEnrichment`; a write failure there does not fail the run. - The enrichment write lands on the record (the Postgres row) immediately, but `resource.json` on the cortex mount is a projection of that row, and `Sources.ResolveResource` catches it up asynchronously, so the result reports `recordEnrichment.projection: "pending"` — a sibling skill reading the record later in the same run can still see the pre-enrichment copy of `resource.json`. - **Deployment precondition:** `commit_ingest` does not yet write `resource.json` (only `identity.json` and `data.json`, and it publishes no `Sources.ResolveResource`), so a record created by `resource-import` or `pcf-commit` has no projected file yet. The marketplace fix for that (spec §9.1) must deploy before this read switch reaches production. ## v1 - Initial release: resolve one saved supplier via Ploutonion `organization-identity` and write cortex `identity.json` under `/organization/local/suppliers/{partnerId}/`. - Routes with marketplace `identityRequestFromPartner` rules: `organizations.identify` when a company number is anchored by jurisdiction or website; otherwise `organizations.resolve`; skip (exit 0) when there is nothing to resolve. - Stamps partner id and timestamp on the wire body. Does not invent firmographics. 11/4/2026
- v1 # Changelog ## v6 - Updated `SKILL.md` (`primaryMarkdown`) after promotion from an embedded skill so `listingBundleFingerprint` differs from the prior embedded Cortex bundle and Curator mints and publishes a `community.listing_versions` row for the top-level skill listing. ## v5 - Promoted from a blueprint-local skill inside `organisation-identity` to a shared publisher skill under `assets/publishers/qonstrue/skills/organisation-identity-write` so both `organisation-identity` and `run-organisation-due-diligence` can reference it. ## v4 - Renamed from `supplier-identity-write` to `organisation-identity-write`, moving with its blueprint's rename to `organisation-identity`. No behaviour change: the cortex write path and `collection_root_for_slug` derivation are unchanged. ## v3 - Writes `identity.json` under the cortex collection the record's own resource type maps to: `ORGANIZATION_ROOT` joined with `collection_root_for_slug(resourceTypeSlug)`, rather than the previous hardcoded `SUPPLIERS_ROOT`. `supplier` aliases to `suppliers`, so a supplier record's path is byte-for-byte unchanged; a customer record's artefacts would now land under `/organization/local/customer/{id}/`. - The write-path keyword is renamed `suppliers_root` → `collection_root`, matching the reader skills' existing name for the same concept. - Blueprint-side only: the marketplace writers (`partnerIdentitySourceBuilder`, `cortexProfile`) remain supplier-rooted, so customer records still have no upstream provisioning path. This change alone does not make customers work. ## v2 - Reads the record from `{collection_root}/{resource_id}/resource.json` on the cortex mount when the blueprint passes `--resource-id` (now wired into the CLI, matching `supplier-ownership-write` and `supplier-financials-write`) — `qb.get_resource` (Postgres) is no longer consulted on that path. A missing or unreadable `resource.json` fails the run explicitly rather than silently falling back. - Best-effort writes the resolved identity back onto the record's own `properties`: `resolvedName` always, `companyNumber` fill-only (a record already holding `2347327` keeps it even when the resolve returns `05001590`, a different company — correcting it is a data decision), and `name` never touched. Reported under `recordEnrichment`; a write failure there does not fail the run. - The enrichment write lands on the record (the Postgres row) immediately, but `resource.json` on the cortex mount is a projection of that row, and `Sources.ResolveResource` catches it up asynchronously, so the result reports `recordEnrichment.projection: "pending"` — a sibling skill reading the record later in the same run can still see the pre-enrichment copy of `resource.json`. - **Deployment precondition:** `commit_ingest` does not yet write `resource.json` (only `identity.json` and `data.json`, and it publishes no `Sources.ResolveResource`), so a record created by `resource-import` or `pcf-commit` has no projected file yet. The marketplace fix for that (spec §9.1) must deploy before this read switch reaches production. ## v1 - Initial release: resolve one saved supplier via Ploutonion `organization-identity` and write cortex `identity.json` under `/organization/local/suppliers/{partnerId}/`. - Routes with marketplace `identityRequestFromPartner` rules: `organizations.identify` when a company number is anchored by jurisdiction or website; otherwise `organizations.resolve`; skip (exit 0) when there is nothing to resolve. - Stamps partner id and timestamp on the wire body. Does not invent firmographics. 11/4/2026