[skyoo2003]

Why

docs/roadmap.md was badly out of sync with the codebase and misrepresented the project to anyone who read it first:

• Phase 1 was framed as "prove the core thesis on AWS before expanding surface area" and listed 6 implemented services. Reality (make stats): 101 services, ~4,460 operations, with deep hand-written coverage well beyond the "Big 6", working cross-service integrations, and a ServicePlugin plugin system.
• Hardcoded numbers had rotted: roadmap said 671/699 passing (now 717 compat tests); README/docs said 96 services (actual 101).

What changed

• docs/roadmap.md — Phase 1 reframed to "AWS Depth & Stabilization" with accurate checkboxes (stub reduction, compat edge cases, stable ServicePlugin API remain open); version-mapping table marks 0.x ← current. Phases 2–4 (multi-CSP prep, Azure pilot, breadth) left intact — still accurate future work matching architecture.md.
• Consistency fixes across README.md, docs/README.md, docs/configuration.md, docs/faq.md, docs/services-matrix.md — pass-count now points at make test-compat instead of a frozen number; every "96 services" → 101.

Numbers reference make stats / make test-compat rather than baked-in values so they can't drift again.

Verification

• make stats → 101 / 4,460 (matches the "100+" wording)
• grep -rn "671/699\|96 services" README.md docs/ → no matches
• Every [x] integration claim backed by an existing file (cloudformation/engine.go, lambda/eventsource.go, s3/notifications.go)

Docs-only; no Changie fragment (matches prior docs-sync PR #52).

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Updates project documentation to accurately reflect the current AWS service coverage, compatibility status, and roadmap focus, and replaces hardcoded metrics with instructions to derive them from make stats / make test-compat so they stay in sync with the codebase.

File-Level Changes

Change	Details	Files
Reframe Phase 1 of the roadmap to describe current AWS depth, stabilization goals, and accurate progress, including compatibility and plugin API work.	Rename Phase 1 to "AWS Depth & Stabilization" and adjust its goal to focus on stabilizing an already broad AWS surface for v1.0. Replace the old "6 core services" framing with a description of 100+ scaffolded services generated from Smithy models. Expand the checklist to call out deep hand-written coverage, cross-service integrations, and the ServicePlugin system as completed items. Mark overall boto3 compatibility as ≥95% with a current ~96% figure and direct readers to make test-compat for live numbers. Add open checklist items for reducing NotImplementedError stubs, closing remaining compat edge cases, and finalizing the stable ServicePlugin API before v1.0. Update the version mapping table to explicitly mark 0.x as the current series.	docs/roadmap.md
Align high-level README documentation with current service counts and compatibility reporting.	Update the feature list to describe 101 AWS services and keep operation counts verified via make stats. Change compatibility wording from a fixed 671/699 passing tests to an approximate ~96% pass rate with instructions to run make test-compat. Update the Services Matrix description link to state 101 services instead of 96.	README.md
Ensure FAQ and docs index reflect the current number of scaffolded services and point to the services matrix as the source of truth.	Increase all "96 AWS services" references to 101 in the FAQ and configuration docs. Clarify in the FAQ that 101 services are scaffolded and routed, with core services at 100% boto3 compatibility. Update the docs index to advertise 101 services in the Services Matrix link description. Adjust configuration docs to say the default run enables all 101 services.	docs/faq.md docs/README.md docs/configuration.md
Make the services matrix report compatibility as a percentage tied to the test target rather than a fixed numerator/denominator count.	Replace the hardcoded 671/699 (96%) figure with an approximate ~96% pass rate. Instruct users to run make test-compat to obtain the current compatibility test counts.	docs/services-matrix.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• You’ve removed most hardcoded counts, but the explicit ~96% phrasing and the list of remaining edge cases (e.g., S3Tables ARN parsing, ServerlessRepo jsonName) may still rot; consider either generalizing this wording or tying it to an automated doc generation step so it stays current.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- You’ve removed most hardcoded counts, but the explicit `~96%` phrasing and the list of remaining edge cases (e.g., S3Tables ARN parsing, ServerlessRepo `jsonName`) may still rot; consider either generalizing this wording or tying it to an automated doc generation step so it stays current.

## Individual Comments

### Comment 1
<location path="docs/faq.md" line_range="32" />
<code_context>
 ### Which services are supported?

-96 AWS services are scaffolded and routed; coverage depth varies. See [services-matrix.md](services-matrix.md) for the canonical list and per-service operation counts. Core services (S3, SQS, DynamoDB, Lambda, IAM, STS, SNS, CloudWatch, KMS, SecretsManager, EventBridge, CloudFormation) pass 100% of their boto3 compatibility tests.
+101 AWS services are scaffolded and routed; coverage depth varies. See [services-matrix.md](services-matrix.md) for the canonical list and per-service operation counts. Core services (S3, SQS, DynamoDB, Lambda, IAM, STS, SNS, CloudWatch, KMS, SecretsManager, EventBridge, CloudFormation) pass 100% of their boto3 compatibility tests.

 ### Does DevCloud work on Windows?
</code_context>
<issue_to_address>
**nitpick (typo):** Consider spelling the service name as "Secrets Manager" for consistency.

Elsewhere in these docs (e.g., the Phase 1 roadmap bullet), this service is written as "Secrets Manager". Updating this instance from "SecretsManager" to "Secrets Manager" will match AWS’s official name and keep the docs consistent.

```suggestion
101 AWS services are scaffolded and routed; coverage depth varies. See [services-matrix.md](services-matrix.md) for the canonical list and per-service operation counts. Core services (S3, SQS, DynamoDB, Lambda, IAM, STS, SNS, CloudWatch, KMS, Secrets Manager, EventBridge, CloudFormation) pass 100% of their boto3 compatibility tests.
```
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}