[PM-39925] feat: scaffold the Bit.Subscription.* and Bit.Invoicing libraries for invoice preview

[kdenney]

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-39925

📔 Objective

Sets up the library skeleton for the preview-driven cart work. There is no user-facing behavior yet: the endpoint groups map no routes, and everything sits behind a feature flag that defaults off.

• Adds the PM36631_PreviewDrivenCart feature flag.
• Scaffolds three libraries under src/Libraries/: Bit.Invoicing (platform tier, which will own the invoice-preview projection) plus two feature-tier endpoint-group shells, Bit.Subscriptions.User and Bit.Subscriptions.Organization.
• Registers the feature libraries in the API host cloud-only (inside a !globalSettings.SelfHosted block). The host owns the route prefixes: the user group mounts at /account/billing/subscription/premium and the organization group at /organizations/{organizationId:guid}/billing/subscription.
• Each group attaches its shared cross-cutting chain (tags, the Application authorization policy, exception handling, and the PM36631_PreviewDrivenCart gate) to an empty group but maps no endpoints yet; those arrive in later slices. Only an authenticated caller is required at the group level, and each future handler will perform its own organization billing authorization check.
• Adds the new projects to the solution, a README per library, and metadata-based endpoint tests that assert the group conventions against a throwaway probe endpoint.
• Un-ignores the Subscriptions.User directory that the stock *.user gitignore pattern was silently hiding.

All three libraries reference Core as a documented deviation from the target billing-library contract (pending Bit.Integrations.Billing, per ADR-0032); each library's README records what it takes from Core.

This branch is stacked on the Stripe SDK upgrade work (PM-36225), which is its base and should merge first.

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Re-reviewed at the current head. The only change since the last pass is a47db11 — it deletes .claude/rules/billing-library-comment-discipline.md and folds a general "Comment discipline" subsection into .claude/skills/writing-server-code/SKILL.md, which resolves the review thread on that rule; no reference to the deleted rule file remains anywhere in the repo, and the skill's frontmatter is unchanged. The library scaffolding is otherwise unchanged and still has nil runtime blast radius: both endpoint groups map zero routes behind WithTags / WithGroupName("internal") / RequireAuthorization(Policies.Application) / WithBasicExceptionHandling() / RequireFeature(PM36631_PreviewDrivenCart), with the flag defaulting off. Service registration is unconditional in src/Api/Startup.cs per earlier feedback, while AddOpenApiEndpointDataSource and the UseEndpoints mapping stay cloud-only — and since AddOpenApiEndpointDataSource short-circuits unless swaggerGen=true (src/HttpExtensions/EndpointDataSourceServiceCollectionExtensions.cs:22-28) there is no duplicate route source at runtime, while dev/generate_openapi_files.ps1 sets swaggerGen without self-host settings so the spec path still sees the groups.

Code Review Details

No new findings this pass.

Re-verified since the previous review:

• The new .csproj files match the shape of the existing libraries under src/Libraries/ (FrameworkReference on Microsoft.AspNetCore.App, InternalsVisibleTo for the paired test project, Bitwarden.Server.Sdk imported only where the [FlagKeyCollection] generator is needed).
• The six new CODEOWNERS entries all assign @bitwarden/team-billing-dev, and no later pattern in the file re-matches those paths, so last-match-wins produces the intended owner.
• The .gitignore negation !src/Libraries/Subscriptions.User/ sits after *.user and before the [Bb]in/ / [Oo]bj/ patterns, so the library sources are tracked while build output stays ignored.
• pm-36631-preview-driven-cart is defined only in InvoicingFeatureFlags — no duplicate key in Core's FeatureFlagKeys.

Dependency review: no manifest version changes. The new .csproj files add only the shared $(XUnitVersion)-style test template already used across test/Libraries/; the lock file churn in src/Api, util/SqlServerEFScaffold, and the test projects is project-reference metadata from the new ProjectReference entries. No net-new external dependency, so no AppSec approval applies.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 63.31%. Comparing base (ac309aa) to head (a47db11).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8208      +/-   ##
==========================================
+ Coverage   63.29%   63.31%   +0.01%     
==========================================
  Files        2401     2406       +5     
  Lines      104043   104091      +48     
  Branches     9426     9429       +3     
==========================================
+ Hits        65857    65904      +47     
- Misses      35930    35931       +1     
  Partials     2256     2256              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[SaintPatrck]

⛏️ PR description mentions new CLAUDE.md files in every library, but I don't see any new CLAUDE.md files, or modifications to existing ones.

[SaintPatrck]

⛏️ ❓ Pointing Claude to LIBRARY.md here is going to pull the entire file into context every time a matching path is touched, even if it's only reading a file in the path. LIBRARY.md contains more than comment-specific details, so the rule name is misleading.

This rule reads like it's relevant when Claude is writing-server-code, where LIBRARY.md is already referenced. Did you observe behavior that warranted duplicating the instructions and reference outside of writing-server-code?

[kdenney]

Yeah originally I had per-library CLAUDE.md files and each had this comment discipline rule inside but a claude reviewer suggested I remove the duplication and add it to a rule file that covers all of billing team's libraries.

The comment rule was essentially our team's attempt at forcing claude to stop writing verbose comments all throughout code that is already self-explanatory. I don't see any mentions of code comments in writing-server-code but I'm happy to relocate this or rethink how best to achieve this if you have any suggestions. Thanks for the feedback!

[SaintPatrck]

writing-server-code is probably a better place for this. Library Shape is already referenced in the skill. If Claude isn't invoking writing-server-code, not reading LIBRARY.md, or not producing the expected results when it is invoked, we should try remediating that first.

[kdenney]

writing-server-code doesn't really say much about the library shape itself; it links out to LIBRARY.md for that. Buuuuut you could make the argument that all server code should follow this sort of comment discipline rule, not just library code. 😄 To that end, I'll add a comment discipline section to writing-server-code that is not library specific, but let me know if you think I should take a different approach. Thanks!

[kdenney]

Added in a47db11