docs: Add CoprrectionOps

docs/astro.config.mjs

@@ -133,6 +133,9 @@ export default defineConfig({
 		'/patterns/taskops/': '/gh-aw/patterns/task-ops/',
 		'/patterns/trialops/': '/gh-aw/patterns/trial-ops/',
 		'/patterns/workqueueops/': '/gh-aw/patterns/workqueue-ops/',
+		'/patterns/shadowops/': '/gh-aw/organization-practices/safe-rollout/',
+		'/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/guides/packaging-imports.mdx

@@ -7,6 +7,10 @@ sidebar:
 
 import { Tabs, TabItem } from '@astrojs/starlight/components';
 
+:::caution[Evolving guidance]
+Enterprise workflow sharing capabilities are actively expanding. For organization-scale patterns such as central repositories, import governance, and access controls, see [Sharing Workflows](/gh-aw/organization-practices/sharing-workflows/). Details may change as the platform matures.
+:::
+
 ## Adding Workflows
 
 You can add any existing workflow you have access to from external repositories.

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,128 @@
+---
+title: Sharing Workflows
+description: Share, reuse, and govern workflows across repositories and organizations.
+sidebar:
+  badge: { text: 'Platform', variant: 'tip' }
+---
+
+:::caution[Evolving guidance]
+Enterprise workflow sharing capabilities are actively expanding. Details in this guide may change as the platform matures.
+:::
+
+Sharing workflows across repositories is an organization practice, not a single design pattern. GitHub Agentic Workflows supports multiple layers of sharing, from installing a complete workflow into a repository to parameterized imports and cross-repository execution.
+
+The recommended enterprise pattern is one central `agentic-workflows` repository that publishes versioned workflow templates and shared components. Consuming repositories install full workflows with `gh aw add` and pull in shared modules through `imports:`.
+
+## Sharing Layers
+
+### Layer 1: Copy or install whole workflows
+
+A repository can pull in a complete workflow from another repository using `gh aw add`:
+
+```bash
+gh aw add acme-org/agentic-workflows/ci-doctor@v1.2.0
+```
+
+`gh aw add-wizard` provides interactive guidance for the same operation. When a workflow is installed, a `source:` field is added to its frontmatter so the origin is tracked. Updates can then be applied later with `gh aw update`.
+
+Version references support semantic tags (`@v1.2.0`), branches (`@main`), and commit SHAs for strict pinning.
+
+### Layer 2: Reusable workflow components
+
+Shared pieces such as common MCP server configuration, security setup steps, or reusable prompt fragments can be imported by any workflow:
+
+```yaml
+imports:
+  - acme-org/shared-workflows/shared/security-setup.md@v2.1.0
+  - acme-org/shared-workflows/shared/mcp/tavily.md@v1.0.0
+```
+
+Imports compose into the consuming workflow at compile time. Frontmatter fields such as `tools:`, `network:`, and `mcp-servers:` are merged so imported configuration is additive.
+
+### Layer 3: Parameterized templates
+
+Shared workflows can accept inputs so the same template is usable across teams with different requirements:
+
+```yaml
+imports:
+  - uses: acme-org/shared-workflows/shared/reviewer.md@v1
+    with:
+      languages: ["go", "typescript"]
+      severity: "high"
+```
+
+The `uses` / `with` syntax makes it possible to share workflows that have team-specific settings while keeping a single maintained source.
+
+### Layer 4: Versioning and update flow
+
+Enterprise sharing depends on a predictable versioning model:
+
+- **Semantic versions** (`@v1.2.0`) for stable workflows that consuming teams can pin.
+- **Branch refs** (`@main`, `@develop`) for pre-release versions during active development.
+- **SHA pins** for strict reproducibility when drift must be ruled out.
+
+Use `gh aw update` to pull upstream changes into installed workflows:
+
+```bash
+gh aw update                        # update all tracked workflows
+gh aw update ci-doctor              # update a specific workflow
+```
+
+Updates apply a three-way merge that preserves local edits while incorporating upstream changes.
+
+### Layer 5: Private and internal sharing controls
+
+Not every workflow should be available for installation everywhere. GitHub Agentic Workflows supports access-based controls:
+
+- **`private: true`** in workflow frontmatter blocks `gh aw add` from installing that workflow into other repositories.
+- Repository and organization visibility settings control who can read the workflow sources at all.
+- `gh aw add` performs access checks before installation and surfaces warnings for workflows from untrusted sources.
+- Org-internal workflow catalogs can be created using organization repositories with appropriate visibility settings.
+
+```yaml
+---
+private: true
+---
+```
+
+### Layer 6: Import caching and lock behavior
+
+Remote imports are resolved at compile time and cached in `.github/aw/imports/` by commit SHA. This means:
+
+- Compiled `.lock.yml` files are fully reproducible: the exact import content is pinned at compile time.
+- Offline compilation works once imports have been downloaded.
+- The SHA cache is shared across refs that resolve to the same commit, reducing redundant network calls.
+
+The `.lock.yml` file and the `.github/aw/imports/` directory should both be committed to the repository so workflow runs are reproducible across environments.
+
+### Layer 7: Cross-repository execution model
+
+Separate from sharing workflow definitions, workflows can operate across repositories at runtime:
+
+- Read other repositories using GitHub tool access configured with appropriate permissions.
+- Check out code from other repositories using cross-repository checkout.
+- Create safe outputs (issues, pull requests, comments) in target repositories using `target-repo` and `allowed-repos`.
+- Explicit authentication (PAT or GitHub App token) and allowlists control which repositories a workflow may write to.
+
+This execution model is covered in detail in [Cross-Repository Workflows](/gh-aw/reference/cross-repository/) and [MultiRepoOps](/gh-aw/patterns/multi-repo-ops/).
+
+## Governance Questions
+
+When workflows are shared across an organization, the important questions are usually operational rather than technical:
+
+- Who owns the source workflow and approves changes.
+- How updates are reviewed and promoted from the central repository to consuming repositories.
+- Which repositories may consume or dispatch to shared workflows.
+- How secrets, permissions, and safe outputs are standardized across teams.
+- When teams may fork a workflow rather than stay on the shared source.
+
+Those decisions affect reliability more than the file format does.
+
+## Related Documentation
+
+- [Reusing Workflows](/gh-aw/guides/packaging-imports/)
+- [Imports Reference](/gh-aw/reference/imports/)
+- [Frontmatter Reference](/gh-aw/reference/frontmatter/) (source, private, resources fields)
+- [Cross-Repository Workflows](/gh-aw/reference/cross-repository/)
+- [SideRepoOps](/gh-aw/patterns/side-repo-ops/)
+- [MultiRepoOps](/gh-aw/patterns/multi-repo-ops/)