Conversational Audit Walkthrough

Audit results

The assistant calls into Demeanor’s MCP server and relays the audit.

Demeanor found 7 such patterns in CatalogService and will keep the original names — no action needed from you:

Needs your decision — one thing to decide:

MapGet("/orders/{id:int}/summary") returns OrderSummary, whose properties will be renamed (F005).

OrderSummary isn’t registered in CatalogJsonContext (the source-generated JSON context) and no code references its properties by name, so Demeanor has no signal that its property names are part of a public contract. After obfuscation, the endpoint would emit {"a": ..., "b": ... } instead of the readable JSON clients expect.

Two ways to fix:

1. Add [JsonSerializable(typeof(OrderSummary))] to CatalogJsonContext — consistent with how Product, Order, and OrderItem are already registered. Also makes this endpoint ready for Native AOT (ahead-of-time compilation that strips reflection-only code paths).
2. [Obfuscation(Exclude = true, ApplyToMembers = true)] on the OrderSummary type — works, but introduces a second mechanism for preserving JSON contracts in a codebase that already uses source-gen for this purpose.

The assistant recommends #1 — keeps one consistent mechanism across the project.

Informational

• LegacyPlugin.SerializeAuditRecord uses a reflection-path JsonSerializer.Serialize call (F009). Not a renaming risk. It only matters if you publish Native AOT — the IL2026/IL3050 analyzer warnings (trimmer/AOT compatibility diagnostics) will surface because reflection-based serialization can’t be statically analyzed.

Which fix for OrderSummary — #1 (source-gen context) or #2 (attribute on the DTO)?

Fix applied

The assistant edits Serialization/CatalogJsonContext.cs — one attribute added:

 [JsonSerializable(typeof(Product))]
 [JsonSerializable(typeof(Order))]
 [JsonSerializable(typeof(OrderItem))]
+[JsonSerializable(typeof(OrderSummary))]
 [JsonSerializable(typeof(List<Product>))]
 [JsonSerializable(typeof(List<Order>))]
 public partial class CatalogJsonContext : JsonSerializerContext { }

The assistant rebuilds and re-audits to confirm the fix:

Build succeeded.
    0 Warning(s)
    0 Error(s)

OrderSummary is now auto-protected — the source-gen context
registration made it visible to PropertyUsageAnalyzer. All 24 types
safe to obfuscate.

Dry-run results

CatalogService is an executable, so the assistant passes include_publics=true to also rename public types — nothing external references this assembly.

The 9% property-rename rate is the signal auto-protection worked as intended — nearly every property belongs to an EF entity, a source-gen JSON DTO, a [Serializable] or Newtonsoft type, or the IOptions POCO. The 31% method-rename rate similarly reflects the MVC and Minimal API surface being preserved.

Ready to run the real obfuscation?

Obfuscation complete

Obfuscated DLL: bin/Release/net10.0/Demeanor/CatalogService.dll (49.6 KB)

A quick smoke test before shipping: launch the obfuscated DLL and curl /orders/1/summary to confirm the JSON shape, then /health to confirm the controller still routes.

Verification

Exclusions hit the right types: EF entities (Product, Order, OrderItem, CatalogDbContext), CatalogOptions (IOptions), LegacyReportDto ([Serializable]), LegacyWebhookPayload (Newtonsoft), HealthController (MVC), plus the compiler-generated anonymous type.

OrderSummary’s property getters are absent from the renamed list, so the JSON output still emits {"id","customerName","lineCount","total"} at runtime. The record’s Equals / GetHashCode / ToString / Deconstruct methods are renamed since they’re not part of the JSON contract.

CI/CD integration

Wiring build-time obfuscation into the .csproj means every Release build produces an obfuscated DLL automatically — no manual demeanor step in CI, no drift between dev builds and shipping builds. The assistant edits CatalogService.csproj:

<ItemGroup>
  <PackageReference Include="WiseOwl.Demeanor.MSBuild" Version="6.*" />
</ItemGroup>

Just the <PackageReference> — the package auto-enables obfuscation for Release builds and auto-skips test projects via IsTestProject.

CI requirements:

• DEMEANOR_LICENSE must be a build-system secret (GitHub Actions secret, Azure DevOps variable, etc.) — never commit the key to the repo.
• No extra install step — dotnet restore pulls WiseOwl.Demeanor.MSBuild via the PackageReference.
• Keep *.report.json as a build artifact so future crash reports can be decoded with demeanor deobfuscate.
• For release-to-release JSON compatibility, pass the prior release’s report to the next build via <DemeanorPriorReport> to preserve the name mapping for any obfuscated fields that ship across versions.

GitHub Actions snippet:

- run: dotnet build -c Release
  env:
    DEMEANOR_LICENSE: ${{ secrets.DEMEANOR_LICENSE }}

Promoting the decision to a project rule

The OrderSummary finding earlier in the session was a needs-decision one — an unregistered handler-return type that the audit can’t resolve on its own. The team decided to register it in the source-generated context. That fix was made in source, so it sticks.

But the pattern — “handler return types should be registered in the source-gen context” — could fire again on the next handler added to this service, and on every other handler in every other service this team owns. Re-running the conversation each time is waste. The assistant offers to capture the decision as a project rule:

{
  "id": "catalog.handler-return-types-must-register",
  "title": "Handler return types should be registered in the source-gen JSON context",
  "severity": "advisory",
  "match": {
    "handlerReturnType": true,
    "registeredInJsonSerializerContext": false
  },
  "rationale": "Unregistered handler return types fall back to the reflection-path serializer, which both breaks Native AOT and prevents the audit from proving property protection. Decided 2026-05-11 in #1287."
}

The assistant writes .demeanor/patterns/handler-return-types-must-register.json, re-runs the audit to confirm the rule fires on the newly-added OrderSummary registration as advisory rather than needs-decision, and the file shows up in the PR diff alongside the source change. The next audit run — on any teammate’s machine, in CI, six months from now — applies this rule without needing the assistant.