docs: add organizational extension strategy to README

[awsjosh]

Summary

Adds organizational extension strategy guidance (two-layer approach and distribution model) to the Extensions section of the README.

Changes

• Added a new "Organizational Complexity" subsection under Extensions in README.md
• Covers Layer 1 (Org-Wide Extensions) and Layer 2 (Team-Specific Extensions) with directory structure examples
• Includes a Distribution Approach section with a lifecycle event table covering AWS updates, org rule changes, team onboarding, and team-specific additions
• Content sourced from the AI-DLC Customer Extensions guide (sections 4 and 6)

User experience

Before: The Extensions section explains how extensions work, lists built-in extensions, and describes how to add your own. There is no guidance on managing extensions across multiple teams or organizations.

After: The Extensions section now includes an "Organizational Complexity" subsection that provides a clear two-layer strategy for org-wide and team-specific extensions, along with a practical distribution approach using git subtree. Organizations can follow this guidance to scale AI-DLC extensions without merge conflicts or modifying shipped files.

Checklist

If your change doesn't seem to apply, please leave them unchecked.

• I have reviewed the contributing guidelines
• I have performed a self-review of this change
• Changes have been tested
• Changes are documented

Test Plan

• Open the README.md and verify the "Organizational Complexity" subsection appears under Extensions, after "Adding Your Own Extensions" and before "Tenets"
• Confirm heading levels are consistent: ### for the subsection, #### for sub-parts
• Verify the two directory structure code blocks render correctly
• Verify the distribution lifecycle table renders correctly
• Confirm no existing content was modified — the addition is purely additive

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

[awsjosh]

@Kalindi-Dev Thanks again for the feecback, I closed the previous PR and updated based on your feedback.

[Kalindi-Dev]

@awsjosh Thanks for addressing the feedbacks.

A note on framing: the Distribution Approach section presents git subtree as "the recommended mechanism," but this is still a broader team discussion. The repo's actual distribution model is GitHub Releases (zip downloads) . The subtree hasn't been validated in practice here, there's no supporting tooling in the codebase, and it's worth noting that the main branch may contain changes not yet in a release. This might be better framed as one possible example rather than the endorsed recommendation.

The directory convention itself (Layer 1 / Layer 2 with org-* and team-* prefixes) looks good and works with the existing extension loader.
Will review and follow-up.

[scottschreckengaust]

Please review RFC #225 and see how "Proposal C" may fit into this instead?

[awsjosh]

Hey @scottschreckengaust, thanks for pointing out #225 - Orgs adopting AI-DLC today have no guidance on managing extensions across multiple teams, this question has consistently surfaced in every workshop, and RFC #225 is still in discussion. This PR fills that gap in the interim using only existing tooling and will map cleanly once that lands.

[awsjosh]

Hey @Kalindi-Dev git subtree is a standard git feature, so this guidance doesn't depend on new tooling in the repo, orgs can use it today alongside the existing zip releases, pinning to a release tag to avoid main drift.