docs: Add CoprrectionOps

docs/astro.config.mjs

@@ -131,8 +131,11 @@ export default defineConfig({
 		'/patterns/researchplanassignops/': '/gh-aw/patterns/research-plan-assign-ops/',
 		'/patterns/batchops/': '/gh-aw/patterns/batch-ops/',
 		'/patterns/taskops/': '/gh-aw/patterns/task-ops/',
+		'/patterns/shadowops/': '/gh-aw/organization-practices/safe-rollout/',
 		'/patterns/trialops/': '/gh-aw/patterns/trial-ops/',
 		'/patterns/workqueueops/': '/gh-aw/patterns/workqueue-ops/',
+		'/patterns/shadow-ops/': '/gh-aw/organization-practices/safe-rollout/',
+		'/organization-practices/shadow-evaluation/': '/gh-aw/organization-practices/safe-rollout/',
 	},
 	integrations: [
 		sitemap(),
@@ -279,12 +282,21 @@ export default defineConfig({
 						{ label: 'Audit Reports', link: '/guides/audit-with-agents/' },
 					],
 				},
+				{
+					label: 'Organization Practices',
+					items: [
+						{ label: 'Overview', link: '/organization-practices/' },
+						{ label: 'Safe Rollout', link: '/organization-practices/safe-rollout/' },
+						{ label: 'Sharing Workflows', link: '/organization-practices/sharing-workflows/' },
+					],
+				},
 				{
 					label: 'Design Patterns',
 					items: [
 						{ label: 'BatchOps', link: '/patterns/batch-ops/' },
 						{ label: 'CentralRepoOps', link: '/patterns/central-repo-ops/' },
 						{ label: 'ChatOps', link: '/patterns/chat-ops/' },
+						{ label: 'CorrectionOps', link: '/patterns/correction-ops/' },
 						{ label: 'DailyOps', link: '/patterns/daily-ops/' },
 						{ label: 'DataOps', link: '/patterns/data-ops/' },
 						{ label: 'DispatchOps', link: '/patterns/dispatch-ops/' },

docs/src/content/docs/organization-practices/index.mdx

@@ -0,0 +1,31 @@
+---
+title: Organization Practices
+description: Guidance for adopting, sharing, and governing agentic workflows across teams and repositories.
+---
+
+Organization Practices collects guidance that matters at team and enterprise scale but does not need to be presented as a standalone design pattern.
+
+Patterns describe durable workflow shapes such as [CorrectionOps](/gh-aw/patterns/correction-ops/) or [MultiRepoOps](/gh-aw/patterns/multi-repo-ops/). Organization practices cover how those patterns are rolled out, shared, and governed across repositories and teams.
+
+This section is the right place for topics such as:
+
+- safe rollout strategies before production writes are enabled
+- workflow sharing across repositories and organizations
+- centralized ownership models for workflow infrastructure
+- platform conventions for versioning, review, and promotion
+
+## Included Topics
+
+### Safe Rollout
+
+[Safe Rollout](/gh-aw/organization-practices/safe-rollout/) describes how to move from report-only or staged behavior to production writes with evidence and control. One technique inside that progression is shadow evaluation, where the workflow writes to a safe non-production target before promotion.
+
+### Sharing Workflows
+
+[Sharing Workflows](/gh-aw/organization-practices/sharing-workflows/) describes how workflows can be reused across repositories and organizations. It covers imports, reusable components, central workflow repositories, and when to use templates or starter repositories.
+
+## Relationship To Other Sections
+
+- Use [Design Patterns](/gh-aw/patterns/) to learn reusable workflow shapes.
+- Use [Guides](/gh-aw/guides/) for task-oriented instructions such as [Reusing Workflows](/gh-aw/guides/packaging-imports/).
+- Use [Reference](/gh-aw/reference/) for exact configuration syntax and field behavior.

docs/src/content/docs/organization-practices/safe-rollout.md

@@ -0,0 +1,78 @@
+---
+title: Safe Rollout
+description: Move from report-only or staged behavior to direct production writes with evidence and control.
+sidebar:
+  badge: { text: 'Rollout', variant: 'caution' }
+---
+
+Safe rollout is the practice of increasing workflow autonomy in steps instead of enabling direct production writes immediately.
+
+The main question is not whether a workflow is useful, but whether it is trusted enough to act on the live system. In practice, teams usually move through a ladder: report-only first, then staged behavior, then a more realistic safe-write technique if needed, and finally direct production writes.
+
+This is especially useful for [CorrectionOps](/gh-aw/patterns/correction-ops/), where the goal is to improve the workflow over time using persisted predictions and later human truth.
+
+## Rollout Ladder
+
+The usual progression is:
+
+1. Start in report-only mode.
+2. Enable `staged` behavior when proposed writes need to be previewed.
+3. Use shadow evaluation when preview mode is not enough and the real write path needs to be exercised safely.
+4. Promote the same workflow to direct production writes.
+
+`staged` and shadow evaluation are not interchangeable. Staged mode is sufficient when the question is what the workflow would do. Shadow evaluation is needed when the question is whether the real write path behaves correctly on a safe non-production target.
+
+## When Staged Is Enough
+
+Use staged mode when the main risk is decision quality rather than operational behavior.
+
+It is usually enough when maintainers only need to review proposed actions, compare alternatives, or inspect whether the workflow's judgment is reasonable before any write is allowed.
+
+## When Shadow Evaluation Is Needed
+
+Use shadow evaluation when staged mode is too weak because the real write path itself needs validation.
+
+This is a good fit when:
+
+- the workflow must update real target objects to prove the behavior is correct
+- concurrency, deduplication, or serialization needs to be tested on a live-like surface
+- maintainers need to inspect the actual produced state, not only proposed intent
+- cross-repository writes, permissions, or dispatch boundaries need to be exercised safely
+
+Shadow evaluation is one technique inside safe rollout, not a separate top-level pattern.
+
+## Design Rules
+
+### Production truth stays authoritative
+
+Do not let the evaluation surface become the new source of truth. Production events and later trusted human actions should remain authoritative.
+
+### Prediction snapshots should be explicit
+
+If later comparison matters, persist what the workflow predicted at decision time. Do not reconstruct predictions from logs.
+
+### Correction evidence needs provenance
+
+Not every later edit should count as trustworthy truth. Record provenance such as actor type, manual versus automated source, trust status, and origin repository role.
+
+### Evaluation surfaces should remain disposable
+
+Keep the shadow target thin. It should support measurement and rollout, not become a second long-lived control plane.
+
+## Example Shape
+
+The common repository split is:
+
+- production repository: emits live events and contains authoritative later human truth
+- ops repository: persists predictions, collects corrections, publishes reports, and updates instructions
+- shadow repository: temporary non-production write target during rollout
+
+That shape is often useful, but it is still rollout guidance rather than a primary pattern. The stronger reusable pattern remains [CorrectionOps](/gh-aw/patterns/correction-ops/).
+
+## Related Documentation
+
+- [CorrectionOps](/gh-aw/patterns/correction-ops/)
+- [SideRepoOps](/gh-aw/patterns/side-repo-ops/)
+- [MultiRepoOps](/gh-aw/patterns/multi-repo-ops/)
+- [Staged Mode](/gh-aw/reference/staged-mode/)
+- [Safe Outputs Reference](/gh-aw/reference/safe-outputs/)

docs/src/content/docs/organization-practices/sharing-workflows.md

@@ -0,0 +1,66 @@
+---
+title: Sharing Workflows
+description: Share, reuse, and govern workflows across repositories and organizations.
+sidebar:
+  badge: { text: 'Platform', variant: 'tip' }
+---
+
+Sharing workflows across repositories is an organization practice, not a single design pattern.
+
+Some teams want a central repository that publishes common workflows. Others want reusable imports, shared components, or starter repositories that teams can adopt and customize. The right choice depends on how tightly the organization wants to synchronize behavior across repositories.
+
+## Common Sharing Models
+
+### Shared source repository
+
+One repository publishes workflow sources and other repositories add them with `gh aw add` or track them via `source:` metadata. This is a good fit when a platform team owns the workflow and downstream repositories should receive updates over time.
+
+### Reusable imports and shared components
+
+Shared imports are useful when the organization wants common building blocks rather than one complete workflow. This works well for common MCP configuration, shared prompts, safety policy, or reusable workflow fragments.
+
+### Starter repositories and templates
+
+Starter repositories and workflow templates are useful when teams need a strong starting point but are expected to diverge. This model favors local ownership over synchronized updates.
+
+### Central ops repositories
+
+A central operations repository is useful when workflows need durable memory, reporting, review, or organization-wide coordination. In that model, individual product repositories often emit signals while the ops repository owns the long-lived automation loop.
+
+## Choosing Between Them
+
+Use a shared source repository when consistency matters more than local autonomy.
+
+Use imports when the common unit is a capability or policy fragment.
+
+Use templates when the organization wants fast adoption but expects teams to customize independently.
+
+Use a central ops repository when workflows need shared history, review queues, reporting, or cross-repository orchestration.
+
+## Governance Questions
+
+When workflows are shared across an organization, the important questions are usually operational rather than technical:
+
+- who owns the source workflow
+- how updates are reviewed and promoted
+- which repositories may consume or dispatch to shared workflows
+- how secrets, permissions, and safe outputs are standardized
+- when teams may fork a workflow rather than stay on the shared source
+
+Those decisions affect reliability more than the file format does.
+
+## Practical Guidance
+
+For synchronized reuse, start with [Reusing Workflows](/gh-aw/guides/packaging-imports/), `gh aw add`, and imports.
+
+For cross-repository control-plane designs, combine this guidance with [SideRepoOps](/gh-aw/patterns/side-repo-ops/) and [MultiRepoOps](/gh-aw/patterns/multi-repo-ops/).
+
+For organizations introducing workflow sharing gradually, it is common to start with templates or starter repositories, then move stable concerns into imports or a shared source repository once conventions have settled.
+
+## Related Documentation
+
+- [Reusing Workflows](/gh-aw/guides/packaging-imports/)
+- [Imports Reference](/gh-aw/reference/imports/)
+- [SideRepoOps](/gh-aw/patterns/side-repo-ops/)
+- [MultiRepoOps](/gh-aw/patterns/multi-repo-ops/)
+- [Workflow Structure](/gh-aw/reference/workflow-structure/)