@geraldmaron/construct 1.4.2 → 1.5.1

package/specialists/org/contracts/qa-to-release-manager.json

@@ -1,7 +1,7 @@
 {
   "id": "qa-to-release-manager",
   "producer": "cx-qa",
-  "consumer": "cx-release-manager",
+  "consumer": "cx-operations",
   "trigger": {
     "intent": [
       "implementation"
@@ -29,8 +29,16 @@
     "All upstream verdicts APPROVED; QA verdict PASS"
   ],
   "postconditions": [
-    "Rollback plan tested, not just described",
-    "Rollout plan has concrete checkpoint signals"
+    {
+      "id": "qa-to-release-manager-pc-0-rollback-plan-tested-not-just-described",
+      "description": "Rollback plan tested, not just described",
+      "postconditionType": "advisory"
+    },
+    {
+      "id": "qa-to-release-manager-pc-1-rollout-plan-has-concrete-checkpoint-signals",
+      "description": "Rollout plan has concrete checkpoint signals",
+      "postconditionType": "advisory"
+    }
   ],
   "description": "",
   "teamBoundary": {

package/specialists/org/contracts/researcher-to-architect.json

@@ -27,8 +27,16 @@
     "Source classes tagged (internal/primary/secondary/tertiary)"
   ],
   "postconditions": [
-    "Architect's ADR cites the primary sources provided",
-    "Any conflicting evidence surfaced, not suppressed"
+    {
+      "id": "researcher-to-architect-pc-0-architect-s-adr-cites-the-primary",
+      "description": "Architect's ADR cites the primary sources provided",
+      "postconditionType": "advisory"
+    },
+    {
+      "id": "researcher-to-architect-pc-1-any-conflicting-evidence-surfaced-not-suppressed",
+      "description": "Any conflicting evidence surfaced, not suppressed",
+      "postconditionType": "advisory"
+    }
   ],
   "description": "",
   "teamBoundary": {

package/specialists/org/contracts/researcher-to-product-manager.json

@@ -33,24 +33,35 @@
     "Evidence threshold stated and met for each requirement"
   ],
   "postconditions": [
-    "PRD Problem section does not reference ticket IDs, roadmap items, or artifact filenames",
-    "Every functional requirement traces to observed user evidence",
+    {
+      "id": "researcher-to-product-manager-pc-0-prd-problem-section-does-not-reference",
+      "description": "PRD Problem section does not reference ticket IDs, roadmap items, or artifact filenames",
+      "postconditionType": "advisory"
+    },
+    {
+      "id": "researcher-to-product-manager-pc-1-every-functional-requirement-traces-to-observed",
+      "description": "Every functional requirement traces to observed user evidence",
+      "postconditionType": "advisory"
+    },
     {
       "id": "prd-has-problem-section",
       "description": "PRD must contain a Problem section",
       "check": "artifact-has-section",
-      "section": "Problem"
+      "section": "Problem",
+      "postconditionType": "executable"
     },
     {
       "id": "prd-numeric-claims-cited",
       "description": "Every numeric claim in the PRD body cites a source (no fabricated percentages or multipliers)",
-      "check": "artifact-claims-cited"
+      "check": "artifact-claims-cited",
+      "postconditionType": "executable"
     },
     {
       "id": "prd-manifest-reviewers",
       "description": "Manifest required reviewers must appear in agent log before handoff",
       "check": "artifact-reviewers-seen",
-      "fromManifest": true
+      "fromManifest": true,
+      "postconditionType": "executable"
     }
   ],
   "description": ""

package/specialists/org/contracts/reviewer-to-security.json

@@ -27,9 +27,23 @@
     "Scope tagged as auth/secrets/payments/user-data"
   ],
   "postconditions": [
-    "Attacker-perspective findings logged",
-    "Threat model updated if architecture surface changed",
-    "threatModelUpdatedAt >= contractStart — prevents post-hoc threat models written after the architecture has shipped"
+    {
+      "id": "reviewer-to-security-pc-0-attacker-perspective-findings-logged",
+      "description": "Attacker-perspective findings logged",
+      "postconditionType": "advisory"
+    },
+    {
+      "id": "reviewer-to-security-pc-1-threat-model-updated-if-architecture-surface",
+      "description": "Threat model updated if architecture surface changed",
+      "postconditionType": "advisory"
+    },
+    {
+      "id": "reviewer-to-security-pc-2-threatmodelupdatedat-contractstart-prevents-post-hoc-threat",
+      "description": "threatModelUpdatedAt >= contractStart — prevents post-hoc threat models written after the architecture has shipped",
+      "postconditionType": "executable",
+      "enforcedVia": "binary-postcondition",
+      "enforcedBy": "security.threat-model-not-post-hoc"
+    }
   ],
   "description": "",
   "teamBoundary": {

package/specialists/org/contracts/test-automation-to-engineer.json

@@ -1,6 +1,6 @@
 {
   "id": "test-automation-to-engineer",
-  "producer": "cx-test-automation",
+  "producer": "cx-qa",
   "consumer": "cx-engineer",
   "trigger": {
     "automation.required": true
@@ -21,8 +21,16 @@
     "Test scaffolding lands before behavioral edits so the test fails for the right reason first"
   ],
   "postconditions": [
-    "Engineer adds at least one failing test that demonstrates the bug or missing behavior before implementing the fix",
-    "Quarantined flaky tests carry an owner and a remediation date"
+    {
+      "id": "test-automation-to-engineer-pc-0-engineer-adds-at-least-one-failing",
+      "description": "Engineer adds at least one failing test that demonstrates the bug or missing behavior before implementing the fix",
+      "postconditionType": "advisory"
+    },
+    {
+      "id": "test-automation-to-engineer-pc-1-quarantined-flaky-tests-carry-an-owner",
+      "description": "Quarantined flaky tests carry an owner and a remediation date",
+      "postconditionType": "advisory"
+    }
   ],
   "description": "",
   "teamBoundary": {

package/specialists/org/contracts/trace-reviewer-to-sre.json

@@ -1,7 +1,7 @@
 {
   "id": "trace-reviewer-to-sre",
-  "producer": "cx-trace-reviewer",
-  "consumer": "cx-sre",
+  "producer": "cx-reviewer",
+  "consumer": "cx-operations",
   "trigger": {
     "trace.anomaly": true,
     "riskFlags": [
@@ -28,8 +28,16 @@
     "Flagged agents meet the minimum trace threshold (20+); insufficient-trace agents deferred"
   ],
   "postconditions": [
-    "SRE adjusts alert thresholds or SLOs based on the cited trace evidence",
-    "Runbook updated for the failure pattern identified at fleet level"
+    {
+      "id": "trace-reviewer-to-sre-pc-0-sre-adjusts-alert-thresholds-or-slos",
+      "description": "SRE adjusts alert thresholds or SLOs based on the cited trace evidence",
+      "postconditionType": "advisory"
+    },
+    {
+      "id": "trace-reviewer-to-sre-pc-1-runbook-updated-for-the-failure-pattern",
+      "description": "Runbook updated for the failure pattern identified at fleet level",
+      "postconditionType": "advisory"
+    }
   ],
   "description": "",
   "teamBoundary": {

package/specialists/org/contracts/user-to-construct.json

@@ -15,16 +15,23 @@
     "shape": "routed-plan",
     "mustContain": [
       "track",
-      "specialists",
-      "dispatchPlan"
+      "specialists"
     ]
   },
   "preconditions": [
     "Session bootstrap completed: project_context and memory_search called, plus relevant repo docs read as needed"
   ],
   "postconditions": [
-    "Intent classified; work category tagged",
-    "Route decision surfaced as a single-sentence plan"
+    {
+      "id": "user-to-construct-pc-0-intent-classified-work-category-tagged",
+      "description": "Intent classified; work category tagged",
+      "postconditionType": "advisory"
+    },
+    {
+      "id": "user-to-construct-pc-1-route-decision-surfaced-as-a-single",
+      "description": "Route decision surfaced as a single-sentence plan",
+      "postconditionType": "advisory"
+    }
   ],
   "description": ""
 }

package/specialists/org/frameworks/cx-architect-constraint-option-failure.md

@@ -0,0 +1,66 @@
+---
+id: cx-architect-constraint-option-failure
+version: 1
+appliesToRole: architect
+summary: >-
+  Walks a design decision from constraint mapping through scored options to
+  the failure modes the chosen option must survive.
+steps:
+  - id: constraint-mapping
+    move: Name the invariants and the constraints
+    question: What are the invariants, and what breaks if they're violated?
+    emits: constraint-map
+    cites: source
+  - id: option-scoring
+    move: Score each option against the constraints
+    question: For each candidate approach, how well does it satisfy the constraint map, and at what cost?
+    emits: option-scoring
+    cites: prior-step
+  - id: decision
+    move: Choose and name what was rejected
+    question: Given the scores, which option is chosen, and why were the others rejected?
+    emits: decision-record
+    cites: prior-step
+  - id: failure-modes
+    move: Enumerate how the chosen option fails
+    question: Under what conditions does the chosen option break, and what is the blast radius of that failure?
+    emits: failure-modes
+    cites: prior-step
+---
+
+Run these four moves before an ADR is written. Each move produces one
+labeled output; the framework exists to prevent decisions that emerged from
+code rather than from deliberate, documented tradeoffs.
+
+**constraint-mapping.** Name the system's invariants — the properties that
+must hold — and the constraints (technical, organizational, regulatory) that
+bound the solution space. `constraint-map` cites the source the invariant or
+constraint comes from: an existing contract, a data model, a compliance
+requirement, a prior ADR. An invented invariant is worse than no invariant —
+write `unknown` when a constraint is suspected but not confirmed.
+
+**option-scoring.** For every candidate approach (including "do nothing"),
+score it against the constraint map: what it satisfies, what it costs, what
+it risks. `option-scoring` cites the constraint map (`prior-step`) — a score
+is a function of the constraints named, not a separate intuition about which
+option "feels right."
+
+**decision.** Choose the option the scoring favors and name specifically why
+the others were rejected — this is the ADR's Rejected Alternatives section.
+`decision-record` cites the option scoring (`prior-step`): the chosen option
+follows from the scores, and the rejection reasons are the scoring
+dimensions the losing options failed on, not a generic "didn't fit."
+
+**failure-modes.** For the chosen option, enumerate the conditions under
+which it breaks and the blast radius of that failure — this is the ADR's
+Consequences and Reversibility material. `failure-modes` cites the decision
+record (`prior-step`): the failure modes are specific to what was actually
+chosen, not a boilerplate risk list that would apply to any option.
+
+Good output: a constraint map with cited invariants, option scores that show
+their work against those constraints, a decision record with ≥2 rejected
+alternatives and specific rejection reasons, and failure modes that name
+concrete breaking conditions and their blast radius. Bad output: a decision
+with no rejected alternatives (the decision defaulted), constraints asserted
+without a source, or failure modes that just restate generic engineering
+risk ("could have bugs").

package/specialists/org/frameworks/cx-engineer-feasibility-blast-radius.md

@@ -0,0 +1,66 @@
+---
+id: cx-engineer-feasibility-blast-radius
+version: 1
+appliesToRole: engineer
+summary: >-
+  Walks an implementation task from a feasibility read through an effort
+  class to a blast-radius assessment naming what could break in integration.
+steps:
+  - id: read-first
+    move: Read the existing pattern before writing
+    question: What does the code that already does something similar look like?
+    emits: feasibility-assessment
+    cites: source
+  - id: effort-class
+    move: Classify the effort
+    question: Given the existing pattern, is this a small, medium, or large change?
+    emits: effort-class
+    cites: prior-step
+  - id: debt-check
+    move: Name debt this change takes on or pays down
+    question: Does this change introduce a shortcut, or does it retire one?
+    emits: debt-note
+    cites: source
+  - id: blast-radius
+    move: Trace what else could break
+    question: What callers, seams, or integration points does this change touch beyond its own file?
+    emits: blast-radius
+    cites: prior-step
+---
+
+Run these four moves before writing implementation code. Each move produces
+one labeled output; skipping "read-first" is the specific failure mode this
+framework exists to prevent.
+
+**read-first.** Grep and read the files this change will touch and the
+files that already solve something similar. `feasibility-assessment` cites
+file:line for every claim about existing behavior or convention — never a
+remembered API shape or an assumed function signature. If the existing
+pattern is genuinely absent, the assessment says so and names what was
+searched.
+
+**effort-class.** Given what read-first found, classify the change as S/M/L
+— matching the `complexity` enum already used in `lib/contract-schemas/decision.json`
+tasks, so the classification is legible to the architect who assigned the
+task. `effort-class` cites the feasibility assessment (`prior-step`): the
+class follows from what the code actually looks like, not from a guess made
+before reading it.
+
+**debt-check.** Name any technical debt this change introduces (a shortcut,
+a TODO, a workaround) or retires (removing dead code, fixing a known
+sharp edge). `debt-note` cites the specific file:line the debt lives in or
+the run/test that shows a shortcut is gone — debt is never asserted in the
+abstract.
+
+**blast-radius.** Trace every caller, seam, or integration point this change
+touches beyond the file being edited — the place where "it works in
+isolation and breaks in integration" would show up. `blast-radius` cites the
+effort class and feasibility assessment (`prior-step`): the radius is
+derived from what was actually read, not a boilerplate "should be low risk."
+
+Good output: a feasibility assessment citing file:line for every claim, an
+effort class that matches the actual diff size once written, a debt note
+that names a specific shortcut or a specific removal, and a blast-radius
+list naming actual callers or integration seams. Bad output: "should be
+straightforward," an effort class assigned before reading any code, or a
+blast-radius section that says "low risk" with no callers named.

package/specialists/org/frameworks/cx-ops-dependency-sequencing.md

@@ -0,0 +1,74 @@
+---
+id: cx-ops-dependency-sequencing
+version: 1
+appliesToRole: operations
+summary: >-
+  Walks an approved plan from dependency mapping through critical path and
+  ownership to a risk register that names timeline-slippage checks.
+steps:
+  - id: dependency-mapping
+    move: Map what blocks what
+    question: For each task, what must complete before it can start?
+    emits: dependency-graph
+    cites: source
+  - id: critical-path
+    move: Trace the longest dependent chain
+    question: Which sequence of blocking tasks sets the floor on total duration?
+    emits: sequenced-tasks
+    cites: prior-step
+  - id: ownership
+    move: Name one owner per task
+    question: Who is accountable for each task in the sequence, by name or role?
+    emits: ownership-matrix
+    cites: source
+  - id: verification
+    move: Attach a verification gate to each task
+    question: What check proves this task is actually done, not just started?
+    emits: verification-gates
+    cites: prior-step
+  - id: slippage-risk
+    move: Register what could slip and by how much
+    question: Where in the sequence is slack thinnest, and what early signal shows slippage?
+    emits: slippage-risk
+    cites: prior-step
+---
+
+Run these five moves in order whenever an architect's decision hands off a
+plan for execution. Each move produces one labeled output; a plan is not
+executable until all five exist.
+
+**dependency-mapping.** For every task in the incoming plan, name what must
+finish first. The `dependency-graph` output cites the contract, manifest, or
+runtime config the dependency is based on — not an assumption about how
+teams "usually" sequence work. A task with no stated dependency is either
+truly independent or the dependency has not yet been found; say which.
+
+**critical-path.** Using the dependency graph, trace the longest chain of
+blocking tasks — the sequence that sets the floor on how fast this can ship
+regardless of parallel capacity. `sequenced-tasks` cites the dependency graph
+(`prior-step`): the sequence is derived from the graph, not from a
+convenient story about task order.
+
+**ownership.** For every task, name one accountable owner — a person or a
+named role, never "the team" or a placeholder. `ownership-matrix` cites the
+same source class as the dependency graph: an owner is asserted because a
+manifest, org chart, or prior handoff says so, not invented to fill the
+matrix.
+
+**verification.** Attach a concrete verification gate to each task: the
+check that proves the task is actually complete. `verification-gates` cites
+the sequenced tasks (`prior-step`) — a gate with no corresponding task, or a
+task with no gate, is an incomplete plan.
+
+**slippage-risk.** Identify where slack is thinnest on the critical path and
+what early, observable signal would show slippage before the deadline
+arrives. `slippage-risk` cites the verification gates (`prior-step`): the
+risk register is built from the same gates that will actually fire, not a
+generic list of things that could go wrong.
+
+Good output: a dependency graph with named sources, a critical path derived
+from that graph, an ownership matrix with no placeholder owners,
+verification gates that map one-to-one to tasks, and a slippage risk entry
+naming an observable early signal. Bad output: "everything can start now"
+(no dependencies drawn), an owner named "the team," or a verification gate
+that just restates the task description.

package/specialists/org/frameworks/cx-pm-value-tradeoff.md

@@ -0,0 +1,66 @@
+---
+id: cx-pm-value-tradeoff
+version: 1
+appliesToRole: product-manager
+summary: >-
+  Walks a product decision from user value through the tradeoff space to a
+  prioritization call, then closes with testable acceptance criteria.
+steps:
+  - id: user-value
+    move: Name the user and the job
+    question: Whose problem is this and what job are they hiring it for?
+    emits: value-statement
+    cites: source
+  - id: tradeoffs
+    move: Surface the tradeoff space
+    question: What does choosing this cost, and who bears it?
+    emits: tradeoff-table
+    cites: source
+  - id: prioritization
+    move: Make the call and say what it defers
+    question: Given the tradeoffs, what ships now and what is explicitly deferred?
+    emits: prioritization-call
+    cites: prior-step
+  - id: acceptance-criteria
+    move: Write acceptance criteria that can fail
+    question: For each requirement, what observable, binary check proves it's done?
+    emits: acceptance-criteria
+    cites: prior-step
+---
+
+Run these four moves in order on every product decision that reaches a PRD,
+meta-PRD, or backlog proposal. Each move produces one labeled output; do not
+skip a move because the answer "seems obvious" — an obvious answer still
+needs its citation.
+
+**user-value.** Name a specific user (a role, a segment, an account — not
+"users" in the abstract) and the job they are hiring this feature for. The
+`value-statement` output cites the customer note, support ticket, research
+artifact, or intake packet the user reality came from. If no such source
+exists yet, the value statement is `unknown` — do not infer a persona to fill
+the gap (see `rules/common/no-fabrication.md`).
+
+**tradeoffs.** For the value statement above, list what this choice costs and
+who bears the cost: engineering time, a deferred feature, a support burden, a
+technical constraint accepted. The `tradeoff-table` output cites the same
+kind of source as the value statement — a tradeoff is not a tradeoff until
+someone bears it, and that someone is named.
+
+**prioritization.** Given the tradeoff table, state what ships now and what is
+explicitly deferred, and why the deferred item can wait. The
+`prioritization-call` output cites the tradeoff table (`prior-step`) — the
+call is a function of the tradeoffs surfaced, not a separate judgment made in
+isolation.
+
+**acceptance-criteria.** Convert the prioritization call into acceptance
+criteria that are binary pass/fail testable — see `skills/roles/product-manager.md`
+for the anti-pattern of subjective criteria. Each criterion in
+`acceptance-criteria` cites the prioritization call it operationalizes
+(`prior-step`). A criterion nobody can fail to meet is not a criterion.
+
+Good output: a value statement naming a specific user and a cited job, a
+tradeoff table naming who bears each cost, a prioritization call that states
+what is deferred and why, and acceptance criteria that could actually fail a
+real build. Bad output: "users want this," an uncited tradeoff, a
+prioritization call with no rejected alternative, or an acceptance criterion
+like "works well."

package/specialists/org/frameworks/cx-qa-risk-based-coverage.md

@@ -0,0 +1,69 @@
+---
+id: cx-qa-risk-based-coverage
+version: 1
+appliesToRole: qa
+summary: >-
+  Walks a test plan from acceptance criteria through risk-based test
+  selection to a coverage-gap register that names what could still slip
+  through untested.
+steps:
+  - id: criteria-to-failure
+    move: Ask how each criterion fails
+    question: For each acceptance criterion, what test actually fails when the criterion is violated?
+    emits: criterion-failure-map
+    cites: source
+  - id: risk-based-selection
+    move: Select tests by risk, not by convenience
+    question: Given the blast radius and effort class of the change, which behaviors carry the most risk if untested?
+    emits: risk-based-selection
+    cites: prior-step
+  - id: verdict
+    move: Run the selected tests and record the verdict
+    question: Did the selected tests pass, and does coverage meet the project threshold?
+    emits: verdict
+    cites: source
+  - id: coverage-gaps
+    move: Name what is still untested
+    question: Which behaviors have no test, and why were they left out?
+    emits: coverage-gaps
+    cites: prior-step
+---
+
+Run these four moves whenever an implementation reaches QA. Each move
+produces one labeled output; the framework exists to prevent tests that
+prove intent without proving the behavior actually breaks when it should.
+
+**criteria-to-failure.** For every acceptance criterion in the incoming
+implementation or PRD, name the specific test that would fail if the
+criterion were violated. `criterion-failure-map` cites the acceptance
+criteria and the test name/assertion that covers it — a criterion with no
+corresponding failing test is not yet covered, regardless of what the
+overall suite reports.
+
+**risk-based-selection.** Using the engineer's effort class and blast radius
+(when supplied), prioritize test effort toward the behaviors most likely to
+break in integration, not toward the easiest tests to write.
+`risk-based-selection` cites the criterion-failure map (`prior-step`): the
+selection is derived from where failure is most likely and most costly, not
+from convention or convenience.
+
+**verdict.** Execute the selected tests and record PASS or FAIL, plus
+coverage against the project threshold. `verdict` cites the test name and
+run log line (or the coverage report) that produced the result — never an
+estimated or assumed outcome. If the report isn't available, the verdict is
+`unknown`.
+
+**coverage-gaps.** Name every behavior that has no test yet, and state why
+it was left out (out of scope, deferred, no reproducible case yet).
+`coverage-gaps` cites the risk-based selection (`prior-step`): a gap is a
+behavior that risk-based-selection identified as worth testing but that
+did not make it into this pass, or a behavior the selection process missed
+entirely and is now being surfaced.
+
+Good output: a criterion-failure map where every criterion names a specific
+failing test, a risk-based selection that explains why the riskiest
+behaviors were tested first, a verdict citing an actual run or report, and a
+coverage-gaps list that names specific untested behaviors with a reason.
+Bad output: a test suite that mocks the behavior under test into
+meaninglessness, a verdict asserted without a citation, or "coverage looks
+good" with no gaps named.

package/specialists/org/groups/engineering-group.json

@@ -5,10 +5,7 @@
   "roles": [
     "architect",
     "engineer",
-    "debugger",
-    "ai-engineer",
-    "data-engineer",
-    "platform-engineer"
+    "debugger"
   ],
   "decisionRights": [
     "architecture",
@@ -23,10 +20,9 @@
   ],
   "escalationPath": [
     "architect",
-    "rd-lead",
     "orchestrator"
   ],
-  "charter": "Design, build, and harden the system. Owns architecture decisions, technology choices, code quality, debugging, AI integration, and the platform underneath. Does not own product framing, user research direction, or release timing. Escalates tech-debt conflicts to R&D leadership.",
+  "charter": "Design, build, and harden the system. Owns architecture decisions, technology choices, code quality, and debugging. AI integration, data pipelines, and platform/infra tooling are cx-engineer skill bundles rather than separate specialists (ai-engineer, data-engineer, platform-engineer folded in; construct-rf26.11), and cx-architect absorbs the pre-architecture framing-gate function rd-lead previously owned. Does not own product framing, user research direction, or release timing.",
   "contact": {
     "slack": "#engineering",
     "email": "engineering@example.com",

package/specialists/org/groups/governance-group.json

@@ -3,8 +3,7 @@
   "name": "Governance Group",
   "owner": "security",
   "roles": [
-    "security",
-    "legal-compliance"
+    "security"
   ],
   "decisionRights": [
     "security-approval",
@@ -22,7 +21,7 @@
     "architect",
     "orchestrator"
   ],
-  "charter": "Keep the system safe to operate and inside its legal envelope. Owns security review, compliance verification, risk assessment, and the audit trail. Does not own implementation or product decisions but can block deployments that violate policy. Escalates policy conflicts to orchestrator.",
+  "charter": "Keep the system safe to operate and inside its legal envelope. Owns security review, compliance verification (legal-compliance folded in; construct-rf26.11), risk assessment, and the audit trail. Does not own implementation or product decisions but can block deployments that violate policy. Escalates policy conflicts to orchestrator.",
   "contact": {
     "slack": "#governance",
     "email": "governance@example.com",

package/specialists/org/groups/operations-group.json

@@ -1,12 +1,9 @@
 {
   "id": "operations-group",
   "name": "Operations Group",
-  "owner": "sre",
+  "owner": "operations",
   "roles": [
-    "release-manager",
-    "sre",
-    "operations",
-    "docs-keeper"
+    "operations"
   ],
   "decisionRights": [
     "deployment",
@@ -21,15 +18,15 @@
     "security-policy"
   ],
   "escalationPath": [
-    "sre",
+    "operations",
     "architect",
     "orchestrator"
   ],
-  "charter": "Keep the system running and shipping. Owns release management, SRE response, ops runbooks, documentation upkeep, and deployment execution. Does not own architecture or product decisions. Escalates reliability vs. change-rate conflicts to architecture/leadership.",
+  "charter": "Keep the system running and shipping. Owns release management, SRE response, ops runbooks, documentation upkeep, and deployment execution (release-manager, sre, docs-keeper folded in; construct-rf26.11). Does not own architecture or product decisions. Escalates reliability vs. change-rate conflicts to architecture/leadership.",
   "contact": {
     "slack": "#operations",
     "email": "operations@example.com",
-    "owner": "sre"
+    "owner": "operations"
   },
   "evidence": [
     "AGENTS.md (rnd profile departments section)"