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:

PluginHeartbeat is created at run time byActivator.CreateInstance<T>() rather than with new (F001).

That by itself is rename-safe — nothing reads the name. It only breaks if the new instance is then serialised, mapped by an ORM, or populated by a container, since those bind by property name. Demeanor can see the construction; it cannot see far enough to know which of those happens next. That is why this is a decision and not an automatic protection.

The remediation says what to look for:

Trace what happens to the instance after it is created. If it is serialised, mapped by an ORM, or resolved by name anywhere downstream, mark the type[Obfuscation(Exclude=true, ApplyToMembers=true)]. If it is only used through its compiled type, resolve the finding as safe-to-rename.

So the assistant reads the call site rather than guessing:

 var beat = Activator.CreateInstance<PluginHeartbeat>();
 beat.PluginName = "legacy-audit";
 beat.Cycle = cycle;
 beat.ReportedAt = DateTime.UtcNow;
 
 return JsonSerializer.Serialize(beat);

That settles it. The instance is serialised, and the collector on the other end binds by property name — so the answer is protect, not safe-to-rename. The assistant recommends the attribute the remediation names.

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.

Protect PluginHeartbeat, or resolve it as safe-to-rename?

Fix applied

The assistant edits Legacy/LegacyPlugin.cs — one attribute, and theusing it needs:

+using System.Reflection;
 using System.Text.Json;
 
 /// <summary>
 /// Heartbeat payload posted to the plugin collector, which binds by property name.
 /// </summary>
+[Obfuscation(Exclude = true, ApplyToMembers = true)]
 public sealed class PluginHeartbeat

The assistant rebuilds and re-audits to confirm the fix. The rebuild is not a formality — demeanor audit reads compiled metadata, so an edit is invisible to it until it is in the assembly:

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

16 findings -> 15. Needs your decision: 1 -> 0.
PluginHeartbeat now carries its own instruction, so the rule has
nothing left to ask. Nothing else moved.

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 PluginHeartbeat finding earlier in the session was a needs-decision one — a reflectively-constructed type whose safety depends on what happens to the instance, which 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 — “payloads our plugin layer builds reflectively get protected” — could fire again on the next payload type 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": "myteam-reflective-payloads",
  "version": 1,
  "predicate-vocab": 1,
  "kind": "type-protection",
  "summary": "Types the plugin layer builds through Activator.CreateInstance(), so each one carries an explicit decision rather than inheriting a default.",
  "reasoning": "Reflective construction is rename-safe on its own; what breaks is what happens to the instance afterwards. Our plugin payloads are serialised to the collector, which binds by property name, so the team's answer for this shape is always protect. Recorded so the next payload type does not have to re-argue it.",
  "remediation": "Apply [Obfuscation(Exclude=true, ApplyToMembers=true)] to the payload type. ObfuscationAttribute is System.Reflection.ObfuscationAttribute.",
  "severity": "informational",
  "provenance": "project",
  "license": "any",
  "when": {
    "predicate": "il-calls",
    "args": { "methods": ["CreateInstance"], "declaring-type": "Activator", "capture": "generic-arg-0" }
  },
  "then": { "freeze": "report", "report-as": "myteam-reflective-payloads" }
}

The assistant writes .demeanor/patterns/myteam-reflective-payloads.json, re-runs the audit to confirm the rule fires on PluginHeartbeat as informational 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.