@unified-product-graph/core 0.32.2 → 0.33.1

package/dist/index.js

@@ -2439,6 +2439,53 @@ var UPG_EDGE_CATALOG = {
   // contained by product / department / team. Hierarchy edges for person
   // are deliberately omitted; adding them only to satisfy a hierarchy
   // audit would invert the orthogonality the type was introduced to express.
+  // ── Org membership and reporting (0.33.0) ───────────────────────────────────
+  // Both edges are `semantic` REFERENCE edges and neither is a reversal of
+  // the containment-free stance recorded immediately above. That note forecloses
+  // HIERARCHY edges added ONLY to satisfy a hierarchy audit; these are neither.
+  // UPG_CONTAINMENT_FREE_TYPES, UPG_VALID_CHILDREN, get_tree and G2b are all
+  // untouched, and node_assigned_to_person was minted cross-domain onto `person`
+  // at 0.32.0 on the same reading.
+  //
+  // DIRECTION IS LOAD-BEARING, not a preference. get_tree reads SOURCE as parent
+  // (see the team_contains_team note above), so a team -> person edge would sit
+  // one classification change away from putting people in the org tree. Sourcing
+  // on `person` makes the containment reading unavailable rather than merely
+  // unchosen. `team_includes_person` classified hierarchy is the shape to refuse.
+  //
+  // CLASSIFICATION IS `semantic` AND NOT `cross-domain`, which the 0.33.0 design
+  // recommended before the guardrail was consulted. `person` and `team` both live
+  // in the team_org domain, so a `cross-domain` label would contradict itself: the
+  // edge crosses no domain boundary, and T1.7 forbids NEW same-domain cross-domain
+  // edges precisely so that debt stops growing. Nothing the design argument
+  // depends on moves: `semantic` enters neither UPG_VALID_CHILDREN nor get_tree,
+  // and G2b is not engaged.
+  // Membership is UNQUALIFIED: no role property on the edge. `role` is already an
+  // entity type with team_staffed_with_role, so a role string here would be a
+  // second role model beside a node type. The consequence is stated rather than
+  // hidden: the graph can say a team has a slot and that a person is on the team,
+  // and not that the person fills the slot. `person_holds_role` is banked, with
+  // its condition the first field graph carrying both where the join is asked for.
+  //
+  // Neither is cross_product_eligible: `person` is not portfolio_shared, so the
+  // 0.18.0 both-endpoints gate rejects the flag regardless of any team-scoping
+  // ruling.
+  person_member_of_team: { forward_verb: "member_of", reverse_verb: "has_member", classification: "semantic", source_type: "person", target_type: "team" },
+  // Cited three times in spec source since 0.17.2 and existing zero times: the
+  // team_contains_team note above, the team-nesting domain guide, and an
+  // anti_patterns entry that instructs users to model a cross-department
+  // reporting line with this edge. An anti-pattern guide is instructional by
+  // construction, so that third site was telling users to use an edge the catalog
+  // would refuse. Minting makes all three true and needs no prose edit.
+  //
+  // semantic, not hierarchy, and the temptation is real: a reporting line IS a
+  // hierarchy in ordinary English, which is exactly why classifying it that way
+  // would put `person` into containment and become the reversal the sibling edge
+  // above is shaped to avoid. The org chart is a reference structure over
+  // containment-free people. Same classification as the membership edge above, so
+  // the person / team / department triangle is decided once rather than three
+  // times.
+  person_reports_to_person: { forward_verb: "reports_to", reverse_verb: "has_report", classification: "semantic", source_type: "person", target_type: "person" },
   team_staffed_with_role: { forward_verb: "staffed_with", reverse_verb: "staffed_in", classification: "hierarchy", source_type: "team", target_type: "role" },
   team_targets_team_okr: { forward_verb: "targets", reverse_verb: "targeted_by", classification: "hierarchy", source_type: "team", target_type: "team_okr" },
   team_reflects_in_retrospective: { forward_verb: "reflects_in", reverse_verb: "reflects", classification: "hierarchy", source_type: "team", target_type: "retrospective" },
@@ -2483,7 +2530,31 @@ var UPG_EDGE_CATALOG = {
   program_reported_via_status_report: { forward_verb: "reported_via", reverse_verb: "reports", classification: "hierarchy", source_type: "program", target_type: "status_report" },
   program_contains_epic: { forward_verb: "contains", reverse_verb: "contained_in", classification: "cross-domain", source_type: "program", target_type: "epic" },
   project_implements_initiative: { forward_verb: "implements", reverse_verb: "implemented_by", classification: "cross-domain", source_type: "project", target_type: "initiative" },
-  project_delivers_epic: { forward_verb: "delivers", reverse_verb: "delivered_by", classification: "cross-domain", source_type: "project", target_type: "epic" },
+  // WIDENED AT 0.33.0, renamed from project_delivers_epic. The epic-only
+  // endpoint could not hold a real tracker import: a Linear dry-run carried 651
+  // project memberships as `properties.linear_project_id` and emitted zero
+  // edges, because the default issue type an adapter produces is `task` and the
+  // only project edge could not reach it. Endpoint-polymorphic over the
+  // work-item set {feature, epic, user_story, task, bug} by the same
+  // construction as planning_cycle_schedules_work_item: the `work_item` token
+  // names the intended semantic domain, the endpoint is the `node` wildcard.
+  //
+  // NOT a `contains` verb, and UPG_VALID_CHILDREN.project is deliberately
+  // untouched. `contains` is this catalog's containment verb and every edge
+  // using it is classification: 'hierarchy', which under G2b obliges a matching
+  // UPG_VALID_CHILDREN pair. That map is Record<parent, child[]> of concrete
+  // type names, so a polymorphic endpoint can never discharge the obligation
+  // its own verb would create. A work item is CONTAINED once (by its epic or
+  // feature) and REFERENCED many times; the parent axis is containment and the
+  // project axis is a reference. Giving project a second containment claim over
+  // the same task is the two-trees problem.
+  //
+  // classification moves cross-domain -> semantic with the widening: pinned to
+  // project -> epic it was a cross-domain pair, and once the endpoint is the
+  // wildcard it is a reference relation between a planning container and
+  // arbitrary work. deliberate_only because project membership is authored,
+  // never inferred from co-occurrence.
+  project_delivers_work_item: { forward_verb: "delivers", reverse_verb: "delivered_by", classification: "semantic", source_type: "project", target_type: "node", deliberate_only: true },
   milestone_gates_release: { forward_verb: "gates", reverse_verb: "gated_by", classification: "cross-domain", source_type: "milestone", target_type: "release" },
   milestone_triggers_release: { forward_verb: "triggers", reverse_verb: "triggered_by", classification: "cross-domain", source_type: "milestone", target_type: "release" },
   deliverable_ships_feature: { forward_verb: "ships", reverse_verb: "shipped_by", classification: "cross-domain", source_type: "deliverable", target_type: "feature" },
@@ -3549,6 +3620,24 @@ var UPG_EDGE_CATALOG = {
   // so the lifecycle is governed rather than a standalone root (0.12.1 refinement).
   operating_lifecycle_defined_by_specification: { forward_verb: "defined_by", reverse_verb: "defines", classification: "semantic", source_type: "operating_lifecycle", target_type: "specification" },
   operating_lifecycle_contains_operating_stage: { forward_verb: "contains", reverse_verb: "belongs_to", classification: "hierarchy", source_type: "operating_lifecycle", target_type: "operating_stage" },
+  // Conformance (0.33.0, RE-OPENED). 0.33.0 planned to mint
+  // product_conforms_to_specification and feature_conforms_to_specification here.
+  // It does not, and the reason is a fact the design missed: the product-to-
+  // foundation links are NOT absent, they live one tier up. See
+  // UPG_CROSS_ONLY_EDGE_TYPES in shapes/document.ts, which has carried
+  // `product_implements_specification`, `product_exposes_specification` and
+  // `feature_conforms_to_specification` as portfolio-native cross-product edges
+  // since 0.9.12, exactly as the section comment above says. The tiers are
+  // disjoint by construction, so minting the same key here is a hard collision,
+  // and minting only the product half would split one question across two tiers
+  // under two near-synonymous names.
+  //
+  // What survives is the real gap, stated here rather than closed: a
+  // `specification` node held INSIDE a single product graph, with no portfolio,
+  // has no conformance edge, because the cross-only tier needs a registry target.
+  // Whether that case is closed by widening the tier or by a catalog edge under a
+  // non-colliding key is a design question and is banked, with its condition the
+  // first single-product graph that models a specification it conforms to.
   // Stewardship: a registry specification is governed by a (registry-hostable) organization (0.9.13).
   specification_governed_by_organization: { forward_verb: "governed_by", reverse_verb: "governs", classification: "semantic", source_type: "specification", target_type: "organization" },
   // Operating-lifecycle cross-edges (0.11.6): a product's journey phase realises a canonical
@@ -3763,7 +3852,11 @@ var UPG_POLYMORPHIC_EDGE_KEYS = [
   // endpoint-polymorphic over the work-item set {feature, epic, user_story, task,
   // bug}. The `work_item` key token names the intended semantic domain; the
   // endpoint is the `node` wildcard.
-  "planning_cycle_schedules_work_item"
+  "planning_cycle_schedules_work_item",
+  // Project membership (0.33.0, widened from project_delivers_epic):
+  // endpoint-polymorphic over the work-item set {feature, epic, user_story, task,
+  // bug}. Same construction and same reasoning as the cadence edge above.
+  "project_delivers_work_item"
 ];
 var _POLY_KEY_SET = new Set(UPG_POLYMORPHIC_EDGE_KEYS);
 function isPolymorphicEdge(key) {
@@ -3820,6 +3913,9 @@ var BASE_NODE_FIELD_PRESENCE = {
   external_tool: true,
   external_ref: true,
   external_id: true,
+  external_links: true,
+  created_at: true,
+  updated_at: true,
   properties: true
 };
 var UPG_BASE_NODE_FIELDS = Object.freeze(
@@ -6911,6 +7007,22 @@ var TEMPLATE_LIFECYCLES = [
   fromTemplate("nps_campaign", OPERATIONAL_TEMPLATE),
   fromTemplate("monitor", OPERATIONAL_TEMPLATE),
   fromTemplate("alert_rule", OPERATIONAL_TEMPLATE),
+  // 0.33.0: agent_skill and agent_hook move here from WORK_ITEM. A durable
+  // capability and an event trigger were both reaching `in_review` and `done`,
+  // which is the wrong shape rather than a missing one: neither is work that gets
+  // reviewed and accepted, and zero of the ten field instances across the corpus
+  // had ever left the initial phase. Their nearest siblings are the two lines
+  // directly above, and `monitor` and `alert_rule` are the same kind of thing:
+  // something that runs continuously, can be paused, and is eventually retired.
+  //
+  // NOT lifecycle-free. The `user_story` precedent for lifecycle-freedom is the
+  // Statement/Implementation split, where the paired `task` carries the
+  // lifecycle. There is no paired entity here, so lifecycle-freedom would leave
+  // `agent_skill` unable to say it is disabled and would entrench
+  // `AgentHookProperties.hook_status` (now @deprecated) as the permanent status
+  // axis, which is the *_status shadow Pattern D collapsed fourteen times.
+  fromTemplate("agent_skill", OPERATIONAL_TEMPLATE),
+  fromTemplate("agent_hook", OPERATIONAL_TEMPLATE),
   fromTemplate("on_call_rotation", OPERATIONAL_TEMPLATE),
   fromTemplate("security_audit", OPERATIONAL_TEMPLATE),
   fromTemplate("penetration_test", OPERATIONAL_TEMPLATE),
@@ -6939,8 +7051,8 @@ var TEMPLATE_LIFECYCLES = [
   fromTemplate("infrastructure_component", MATURITY_TEMPLATE),
   // ── Phase C: WORK_ITEM (todo / in_progress / in_review / done) ──────────────
   fromTemplate("agent_task", WORK_ITEM_TEMPLATE),
-  fromTemplate("agent_skill", WORK_ITEM_TEMPLATE),
-  fromTemplate("agent_hook", WORK_ITEM_TEMPLATE),
+  // agent_skill and agent_hook moved WORK_ITEM -> OPERATIONAL at 0.33.0; see the
+  // OPERATIONAL block below. agent_task stays: a task IS a work item.
   // UPG-690 (0.21.0): task (exact match) + epic (todo→in_progress→done ⊆ WORK_ITEM,
   // in_review becomes available — non-breaking widening) folded off hand-authored.
   fromTemplate("task", WORK_ITEM_TEMPLATE),
@@ -10005,6 +10117,16 @@ function getScalarToEdgeMigrations(fromVersion, toVersion) {
   return result;
 }
 var UPG_EDGE_MIGRATIONS = {
+  "0.33.0": [
+    // G1 — the project membership edge widens from epic to the work-item set.
+    // Same construction as the 0.32.0 cadence rename directly below, and for the
+    // same measured reason: the adapters default an unrecognised issue to `task`,
+    // so the type a project most needed to deliver was the one type it could not
+    // reach. No requires_target_type, because the destination's target_type is
+    // the `node` wildcard and endpoint guards check the catalog's declared type
+    // rather than the concrete instance. Gate only on the unwidened source.
+    { kind: "rename", from: "project_delivers_epic", to: "project_delivers_work_item", requires_source_type: "project", reason: "0.33.0: a project could only deliver an epic, while a Linear dry-run carried 651 project memberships as properties.linear_project_id and emitted zero edges. Widened to the polymorphic work-item endpoint; no flip, source unchanged. Measured live population of the old type at release: one, in the CI saturation fixture, so this rename is a vocabulary change rather than a data migration." }
+  ],
   "0.32.0": [
     // C5 — the cadence scheduling edge widens from user_story to the work-item
     // set. No requires_target_type: the destination's target_type is the `node`
@@ -10823,6 +10945,41 @@ function migrateEdge(edge, fromVersion, toVersion, endpoints) {
 // src/grammar/status-migrations.ts
 var UPG_STATUS_MIGRATIONS = {
   // ── Engineering / Operations ─────────────────────────────────────────────
+  // ── Agent automation: WORK_ITEM -> OPERATIONAL (0.33.0) ──────────────────
+  // agent_skill and agent_hook carried WORK_ITEM until 0.33.0, so every graph
+  // written before it holds WORK_ITEM phase ids against an OPERATIONAL
+  // lifecycle. Measured population at release: 4 nodes, all `todo`. The other
+  // five entries cover the phases those graphs could legally have reached.
+  //
+  // in_review maps to `active` rather than to a review phase because OPERATIONAL
+  // has none: a hook awaiting review is still a hook that is running or about to.
+  // cancelled maps to `sunset` rather than `completed`: OPERATIONAL has no
+  // cancelled bucket and a discontinued trigger is wound down, not finished.
+  agent_skill: {
+    todo: "planning",
+    backlog: "planning",
+    in_progress: "active",
+    in_review: "active",
+    done: "completed",
+    cancelled: "sunset"
+  },
+  agent_hook: {
+    todo: "planning",
+    backlog: "planning",
+    in_progress: "active",
+    in_review: "active",
+    done: "completed",
+    cancelled: "sunset",
+    // The AgentHookProperties.hook_status vocabulary, @deprecated at 0.33.0 as a
+    // *_status shadow of the base `status`. `error` maps to `paused` and NOT to a
+    // failure phase: OPERATIONAL has none, and runtime health is store or
+    // telemetry state rather than a fact about the thing. That is the same cut
+    // that kept composition.rev, which is a fact, and excluded a concurrency
+    // token, which is not. The failure detail belongs in `description` or a
+    // diagnostic property.
+    disabled: "paused",
+    error: "paused"
+  },
   service: {
     // Lifecycle: [development, staging, production, deprecated]
     // Authoring habit from before lifecycle adoption: every long-lived
@@ -11272,7 +11429,7 @@ var UPG_PROPERTY_SCHEMA = {
   agent_hook: {
     hook_event: { type: "string", description: "Event that triggers this hook" },
     hook_action: { type: "string", description: "Action performed when the hook fires" },
-    hook_status: { type: "string", enum: ["active", "disabled", "error"], description: "Operational status of the hook" },
+    hook_status: { type: "string", enum: ["active", "disabled", "error"], description: "Operational status of the hook. @deprecated since 0.33.0, removeIn 1.0.0. Use the base `status` field. `agent_hook` moved from the WORK_ITEM lifecycle to OPERATIONAL at 0.33.0, whose phases carry this axis directly: `active` maps to `active` and `disabled` maps to `paused`. A `*_status` property beside the base `status` is the shadow that Pattern D collapsed fourteen times at 0.15.0, and a type that models its own status in a property is a type whose lifecycle did not fit. `error` maps to `paused`: OPERATIONAL has no failure phase, and runtime health is store or telemetry state rather than a fact about the thing, which is the same cut that keeps `composition.rev` and excludes a concurrency token. Put the failure detail in `description` or a diagnostic property." },
     execution_count: { type: "number", description: "Number of times this hook has fired", modifier: "snapshot" }
   },
   // AgentSessionProperties: Agent session.
@@ -11809,12 +11966,12 @@ var UPG_PROPERTY_SCHEMA = {
   },
   // CompositionProperties
   composition: {
+    member_query: { type: "object", description: "When present, membership is DERIVED: members are produced by running this query rather than authored by placement.", notes: "This is the portable statement of what the layer shows. On a composition, `CompositionMember.href` remains the publishing tool's own resolved route and stays opaque to everyone else; a member may carry both, and then the href is a fast path while the query is the meaning. A consumer that cannot parse the href can still render the layer, which is the whole reason the declaration is here rather than in a tool-namespaced bag key. A layer with no `member_query` is authored, which is what every composition written before 0.32.0 is. DECLARED ON BOTH HALVES OF THE PAIR since 0.33.0. A layer is query-driven while it is being worked on, not only once it is published, so declaring the query only on the durable composition would make it a fact invented at publish time rather than one recorded." },
+    presentation: { type: "object", description: "Advisory rendering intent for the layer as a whole. A consumer may ignore it entirely and still be conformant." },
     members: { type: "object[]", description: "The frozen member arrangement, captured at publish. Layout and pointers only, never resolved content." },
     rev: { type: "number", description: "Monotonic revision, bumped on each republish of the same slug.", notes: "A published revision is a fact about the composition, user-visible as a new print from the same plate, so it is serialised. Worth distinguishing from a store's concurrency token, which shares the name in some backends but is a fact about the table rather than about the thing, and is not spec data." },
     published_at: { type: "string", description: "ISO timestamp of the most recent publish or republish." },
-    published_by: { type: "string", description: "Publisher handle or email. Display scalar, same posture as `WorkspaceProperties.owner`." },
-    member_query: { type: "object", description: "When present, membership is DERIVED: members are produced by running this query rather than authored by placement.", notes: "This is the portable statement of what the composition shows. `CompositionMember.href` remains the publishing tool's own resolved route and stays opaque to everyone else; a member may carry both, and then the href is a fast path while the query is the meaning. A consumer that cannot parse the href can still render the layer, which is the whole reason the declaration is here rather than in a tool-namespaced bag key. A composition with no `member_query` is authored, which is what every composition written before 0.32.0 is." },
-    presentation: { type: "object", description: "Advisory rendering intent for the composition as a whole. A consumer may ignore it entirely and still be conformant." }
+    published_by: { type: "string", description: "Publisher handle or email. Display scalar, same posture as `WorkspaceProperties.owner`." }
   },
   // ConfigurationAxisProperties: A named dimension along which the product's composition differs.
   configuration_axis: {
@@ -12077,7 +12234,7 @@ var UPG_PROPERTY_SCHEMA = {
     budget: { type: "number", description: "Allocated budget for this program" },
     target_leads: { type: "number", description: "Target number of leads to generate" }
   },
-  // DepartmentProperties: Department entity.
+  // DepartmentProperties: Department entity. A department is the single org tier above a team.
   department: {
     headcount: { type: "number", description: "Total number of people in the department", modifier: "snapshot" },
     budget: { type: "number", description: "Annual budget allocated to the department" },
@@ -13231,7 +13388,7 @@ var UPG_PROPERTY_SCHEMA = {
   },
   // ObjectiveProperties: A high-level strategic goal. The O in OKR.
   objective: {
-    timeframe: { type: "string", description: 'Planning timeframe (e.g. "Q1 2026", "H1 2026")' },
+    timeframe: { type: "string", description: 'Planning timeframe (e.g. "Q1 2026", "H1 2026"). @deprecated since 0.33.0, removeIn 1.0.0. Promote the period to a `planning_cycle` node and link it with the `objective_scoped_to_planning_cycle` edge, which has existed since 0.20.0 and points at a shared, dated, nestable interval instead of a drifting per-objective string. Until promoted, the value is a display label and nothing schedules on it. The promotion is documented rather than automated and no `drop_props` migration ships: which cycle a free-text string means, and whether one exists yet, is a judgement, and dropping the string before the cycle exists destroys the only record of the intent. @example "Q1 2026", "H1 2026"' },
     progress: { type: "number", description: "Overall progress (0\u2013100)" }
   },
   // ObservationProperties: Discrete observation captured during research. Absorbed from the deprecated Highlight entity.
@@ -13452,7 +13609,7 @@ var UPG_PROPERTY_SCHEMA = {
     logo_url: { type: "string", description: "Logo or icon URL. Used to render product cards and lists.", modifier: "volatile" },
     launched_at: { type: "string", description: "When the product became generally available (ISO 8601)" },
     described_configuration: { type: "string", description: 'The product configuration this graph describes, named in plain language. A label for readers: nothing reads it to gate, filter, or alter how a tool interprets the graph. @example "Enterprise plan, split-navigation flag on"', notes: "A product's composition often differs by feature flag, plan tier, permission level or beta programme: surfaces appear, disappear, or are replaced by different surfaces with different occupants. A graph that models one of those without saying which is qualified by a condition nobody wrote down, and every fact in it inherits that silence. It makes no claim about which configuration most customers are on. Where a product genuinely ships several and the differences matter, declare a `configuration_axis` instead and let each fact say which values it holds under." },
-    key_prefix: { type: "string", description: 'Prefix for keys minted onto this product\'s nodes (e.g. `"LTN"`, giving `LTN-1`, `LTN-2`, \u2026). A product with no prefix mints no keys. @example "LTN"', notes: 'Pairs with `UPGBaseNode.key`, which holds the minted value. The prefix sits on the product because the key\'s uniqueness scope is the product, across entity types; the namespace a tracker calls a "team". Only the prefix is serialised: the next number is `max(existing) + 1`, derived from the graph, because a counter is a fact about a store rather than about the product.' }
+    key_prefix: { type: "string", description: 'Prefix for keys minted onto this product\'s nodes (e.g. `"LTN"`, giving `LTN-1`, `LTN-2`, ...). Retained as the single-team unasked default. @deprecated since 0.33.0, removeIn 1.0.0. Use `team.key_prefix`. This field\'s own summary called the prefix "the namespace a tracker calls a team", and a single string cannot express a product with two of them: a two-team product has never been expressible, which is a defect rather than an unused feature. Ignored whenever any team in the product declares a prefix. Deprecated rather than removed because removal would strand every graph that has a product prefix and no `team` nodes. @example "LTN"', notes: "Pairs with `UPGBaseNode.key`, which holds the minted value and states the resolution order normatively. Only the prefix is serialised: the next number is `max(existing) + 1`, derived from the graph, because a counter is a fact about a store rather than about the product. WHY THIS IS NOT A DEFAULT WITH `team.key_prefix` AS AN OVERRIDE. A default and an override describe one fact at two scopes. These describe different facts, and this one is correct only when the product has exactly one team, which is an accident of arity rather than a scope. Keeping it live as a fallback would also reintroduce the defect: a prefix that still resolves wins on ladder order, so a legacy-prefixed product with two teams would offer no choice at all and mint everything under the legacy prefix silently, with migration order deciding the behaviour per graph." }
   },
   // ProductAreaProperties: ProductArea entity.
   product_area: {
@@ -13941,7 +14098,7 @@ var UPG_PROPERTY_SCHEMA = {
   // StrategicThemeProperties: StrategicTheme entity.
   strategic_theme: {
     owner: { type: "string", description: "Owning person or team. Promote to a `node_owned_by_person` edge if ownership must be queryable." },
-    time_horizon: { type: "string", description: 'Bounded period this theme is active (a theme is time-bound, within a pillar). @deprecated since 0.20.0. Promote the period to a `planning_cycle` node and link it with the `strategic_theme_scoped_to_planning_cycle` edge, which points at a shared, dated, nestable interval instead of a drifting per-theme string. Kept (not removed) for back-compat; removal is a later major. `strategic_pillar.time_horizon` stays as-is (a durable pillar horizon is genuinely open-ended, not a dated cycle). @example "Q1 2026", "FY26"' },
+    time_horizon: { type: "string", description: 'Bounded period this theme is active (a theme is time-bound, within a pillar). @deprecated since 0.20.0, removeIn 1.0.0. Promote the period to a `planning_cycle` node and link it with the `strategic_theme_scoped_to_planning_cycle` edge, which points at a shared, dated, nestable interval instead of a drifting per-theme string. Kept (not removed) for back-compat. The removal version is stated at 0.33.0 because an undated deprecation is how this field survived twelve minors; the promotion is documented rather than automated and no `drop_props` migration ships. `strategic_pillar.time_horizon` stays as-is (a durable pillar horizon is genuinely open-ended, not a dated cycle). @example "Q1 2026", "FY26"' },
     description: { type: "string", description: "Short narrative of this time-bound thrust within its pillar" },
     scope: { type: "string", description: "What the theme explicitly includes or excludes" }
   },
@@ -14060,7 +14217,8 @@ var UPG_PROPERTY_SCHEMA = {
   team: {
     team_type: { type: "string", enum: ["product", "engineering", "design", "growth", "customer_success"], description: "Functional area of the team" },
     size: { type: "number", description: "Number of people on the team" },
-    mission: { type: "string", description: "Team's mission statement" }
+    mission: { type: "string", description: "Team's mission statement" },
+    key_prefix: { type: "string", description: 'Prefix this team mints node keys with (e.g. `"ENTP"`, giving `ENTP-1`, `ENTP-2`, ...). @example "ENTP"', notes: "SUPERSEDES `product.key_prefix` FOR THIS PRODUCT. The moment any team declares a prefix, the product-level prefix stops being consulted and the declared team prefixes become the candidate set a create surface offers. A product-level prefix that still resolved would win on order alone, and a multi-team product would then silently mint everything under it, which is the defect this field exists to end. A DECLARED PREFIX IS A CANDIDATE BEFORE IT IS OBSERVED. Candidates derived only from keys that already exist cannot see a team's first create, which is the one that most needs asking about. UNIQUENESS IS PRODUCT-SCOPED, AND A TEAM PREFIX DOES NOT WIDEN IT. The key sequence runs per product across entity types, so two teams in one product share one number line and never collide with each other. A team prefix names a team WITHIN that scope; it does not create a sequence that spans products. MINTING IS PRODUCT-SCOPED (normative, 0.33.0). `team` is `portfolio_shared`, so one team node can be referenced from two products. Minting is not portfolio-scoped with it. The rule, and it is a requirement rather than a recommendation: 1. A portfolio-shared team's prefix is NOT a minting candidate in a second product. The first product a team mints under is the only product that prefix mints in. 2. Refusal is NO-KEY. The node is created without a key. Refusal MUST NOT be an exception: a keyless create is a legal outcome everywhere else in the ladder, and throwing here would break creates that succeed today on every surface. Throwing stays reserved for a broken invariant, not for policy. 3. The rule applies on the MINT path, not the picker path, and it covers the INFERRED case. A prefix that was never requested by anyone, and was derived from keys that already exist in the second product, is refused on the same terms as one a caller named. A guard that only inspects an explicitly requested prefix misses the quiet path, and the quiet path is the one a fixture reproduces. WHY THE SCOPE STOPS AT THE PRODUCT. Key uniqueness is enforced by a `(product_id, key)` index, which permits the same key under two product ids by construction. A prefix that minted in two products would therefore run two independent sequences under one name and hand two different nodes the same citation, with nothing objecting. Portfolio-shared team minting is DEFERRED until a supra-product uniqueness design exists, rather than approximated. This rule states the CONTRACT. The behaviour belongs to whatever mints keys, which is not this package: see `UPGBaseNode.key`." }
   },
   // TeamOkrProperties: TeamOkr entity.
   team_okr: {
@@ -14386,6 +14544,8 @@ var UPG_PROPERTY_SCHEMA = {
   },
   // WorkspaceProperties: Workspace: a spatial thinking space for arranging entities.
   workspace: {
+    member_query: { type: "object", description: "When present, membership is DERIVED: members are produced by running this query rather than authored by placement.", notes: "This is the portable statement of what the layer shows. On a composition, `CompositionMember.href` remains the publishing tool's own resolved route and stays opaque to everyone else; a member may carry both, and then the href is a fast path while the query is the meaning. A consumer that cannot parse the href can still render the layer, which is the whole reason the declaration is here rather than in a tool-namespaced bag key. A layer with no `member_query` is authored, which is what every composition written before 0.32.0 is. DECLARED ON BOTH HALVES OF THE PAIR since 0.33.0. A layer is query-driven while it is being worked on, not only once it is published, so declaring the query only on the durable composition would make it a fact invented at publish time rather than one recorded." },
+    presentation: { type: "object", description: "Advisory rendering intent for the layer as a whole. A consumer may ignore it entirely and still be conformant." },
     visibility: { type: "string", enum: ["private", "shared", "public"], description: "Who can see this workspace" },
     purpose: { type: "string", description: "Free-text description. Pairs with the closed-enum `workspace_purpose`." },
     workspace_purpose: { type: "string", enum: ["discovery", "planning", "retrospective", "design", "research", "strategy", "general"], description: "What the workspace is for. Drives template suggestions and surfaces in workspace browsers.", notes: "`discovery` is persona, job and opportunity exploration. `planning` covers roadmap and decision sessions. `retrospective` is reflection on shipped work. `design` is experience or UI exploration. `research` organises study data and synthesis. `strategy` is high-level direction setting. `general` is the catch-all." },
@@ -32591,6 +32751,9 @@ var NODE_KEY_ORDER = [
   "external_tool",
   "external_ref",
   "external_id",
+  "external_links",
+  "created_at",
+  "updated_at",
   "sort_order",
   "properties"
 ];
@@ -32873,7 +33036,7 @@ function checkHeaderSealText(text) {
 }
 
 // src/index.ts
-var UPG_VERSION = "0.32.2";
+var UPG_VERSION = "0.33.1";
 var UPG_FORMAT_VERSION = "0.4.0";
 var MARKDOWN_FORMAT_VERSION = "0.1";
 var UPG_TYPES = getTypes();
@@ -32958,6 +33121,7 @@ export {
   LEGACY_PRODUCT_STAGES,
   MARKDOWN_FORMAT_VERSION,
   MARKET_COMPETITIVE_PLAYBOOK,
+  NODE_KEY_ORDER,
   OPERATIONS_QUALITY_PLAYBOOK,
   PRESENT_UNDER_PROPERTY,
   PRODUCT_DELIVERY_PLAYBOOK,