docs(specs): FR6 family + ADR-0010 (template.output parser-on-receipt codegen)

Brainstormed re-scope of the original FR6 draft. The new structure:

ADR-0010 — cross-port contract:
- Codegen emits a typed parser-on-receipt for every template.output (not
  provider-side schemas, not combined workflow handles).
- Per-port idiomatic emission: TS dual API (parse + safeParse), C# Parse/
  TryParse, Python parse_xxx throws, Java parseXxx throws.
- Soft cross-port contract: every port's generated parser documents its
  failure mode in docstring/JSDoc/XML doc.
- @payloadRef symmetric with template.prompt (no new @outputRef attribute).
- meta verify extends to cover output drift; diagnostic output gains
  kind: "prompt" | "output" on each finding.

Per-port FRs:
- FR6 parent — cross-port design.
- FR6-ts (plan-of-record): outputParser() generator factory, dual-API Zod
  emission, verify.ts per-subtype branch, template-output-simple conformance
  fixture.
- FR6-csharp (sketch): lighter brainstorm; C# codegen layer ready.
- FR6-python (sketch, gated): Python codegen layer not shipped yet (post-H3).
- FR6-java (sketch, gated): Java codegen layer not shipped yet (H4).

Supersedes the original 2026-05-25-fr-template-output-codegen-pipeline-
design.md (deleted; was a single under-scoped design proposal).

Roadmap updated to reflect the family.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Author: dmealing

docs/superpowers/specs/2026-05-25-fr-template-output-codegen-pipeline-design.md

@@ -0,0 +1,72 @@
+# FR6-csharp — C# `template.output` parser codegen (sketch)
+
+**Status:** Design proposal — needs brainstorm before implementation (lighter brainstorm than TS — C# codegen layer is already mature)
+**Date:** 2026-05-25
+**Scope:** C# — `MetaObjects.Codegen` (parser emission) + `meta verify` extension (C# CLI per CLAUDE.md)
+**Depends on:** [ADR-0010](../../../spec/decisions/ADR-0010-template-output-parser-codegen.md); existing `MetaObjects.Render` + `MetaObjects.Codegen` (shipped per CLAUDE.md status)
+**Parent:** [FR6 cross-port design](./2026-05-25-fr6-template-output-parser-codegen.md)
+
+## Goal
+
+For every declared `template.output`, the C# codegen emits a parser class with the
+dual-API shape from ADR-0010 (matching .NET BCL `Parse`/`TryParse` convention):
+
+```csharp
+// Generated NpcResponse.Output.cs
+public static class NpcResponseOutputParser {
+    private static readonly JsonSerializerOptions Options = new() {
+        PropertyNamingPolicy = JsonNamingPolicy.CamelCase,
+    };
+
+    /// <summary>Parse an LLM response into a typed NpcResponse.</summary>
+    /// <exception cref="JsonException">when JSON parse fails or shape doesn't match.</exception>
+    public static NpcResponse Parse(string text) =>
+        JsonSerializer.Deserialize<NpcResponse>(text, Options)
+            ?? throw new JsonException("null response");
+
+    /// <summary>Parse with Result-style return; does not throw.</summary>
+    public static bool TryParse(string text, out NpcResponse? result, out JsonException? error) {
+        try { result = JsonSerializer.Deserialize<NpcResponse>(text, Options); error = null; return result is not null; }
+        catch (JsonException ex) { result = null; error = ex; return false; }
+    }
+}
+```
+
+Plus `meta verify` extension (C# CLI's `verify` command per CLAUDE.md).
+
+## Why this is a sketch, not implementation-ready
+
+The design largely follows the TS FR6 shape but with .NET idioms. The brainstorm
+items expected:
+
+1. **Source-generator vs reflection.** .NET AOT prefers source generators (per
+   ADR-0001's reflection-replacement principle). The TS port uses Zod (runtime
+   validation). The C# port should use `System.Text.Json` source generators for AOT
+   compatibility — but this needs confirmation against the existing C# codegen
+   patterns. Existing `MetaObjects.Codegen` may already establish a preference.
+2. **JsonNamingPolicy.** C# convention is PascalCase properties; JSON convention is
+   camelCase. The existing C# codegen for entities + payload-VOs has presumably
+   already made this choice. The output parser should match.
+3. **Nullable reference type contracts.** `Parse` returns `T` non-null; `TryParse`'s
+   `out result` is `T?`. Match existing `MetaObjects.Codegen` patterns.
+
+## Tests + verification
+
+- Unit tests on the field-type → System.Text.Json attribute mapping.
+- Golden tests under `MetaObjects.Codegen.Tests/Golden/` matching existing
+  C# codegen test patterns.
+- New conformance fixture `template-output-simple` shares structure with TS; C#
+  conformance runner verifies `expected/NpcResponseOutput.Output.cs` byte-match.
+- `meta verify --kind output` tests under the C# CLI test project.
+
+## Out of scope
+
+Same exclusions as FR6 parent.
+
+## Open questions
+
+To be settled during the lighter brainstorm:
+
+1. System.Text.Json source generator vs runtime reflection.
+2. JsonNamingPolicy choice (probably already established by existing C# codegen).
+3. Whether to ship a barrel/index file aggregating all output parsers, or stay file-per-template (matches C# codegen layout established by existing entity emit).

docs/superpowers/specs/2026-05-25-fr6-csharp-template-output-parser.md

@@ -0,0 +1,92 @@
+# FR6-java — Java `template.output` parser codegen (sketch, gated)
+
+**Status:** Design sketch — gated on Java codegen layer (planned in H4)
+**Date:** 2026-05-25
+**Scope:** Java — codegen target (planned per roadmap H4: "TS codegen Java target — Refactor TS codegen to pluggable targets; Java target emits Spring JDBC DAOs, Spring MVC controllers, POJOs")
+**Depends on:** [ADR-0010](../../../spec/decisions/ADR-0010-template-output-parser-codegen.md); Java codegen layer existing (not yet)
+**Parent:** [FR6 cross-port design](./2026-05-25-fr6-template-output-parser-codegen.md)
+
+## Goal
+
+For every declared `template.output`, the Java codegen emits a parser class with
+the Java throw-only convention (matching Jackson):
+
+```java
+// Generated NpcResponseOutputParser.java
+public final class NpcResponseOutputParser {
+    private static final ObjectMapper MAPPER = new ObjectMapper()
+        .registerModule(new JavaTimeModule());
+
+    /**
+     * Parse an LLM response into a typed NpcResponse.
+     *
+     * @throws JsonProcessingException when JSON parse or schema validation fails
+     */
+    public static NpcResponse parseNpcResponse(String text) throws JsonProcessingException {
+        return MAPPER.readValue(text, NpcResponse.class);
+    }
+}
+```
+
+Plus eventual `meta verify` extension when a Java CLI surfaces (today's
+metaobjects CLI is TS; Java may share or grow its own).
+
+## Why this is a sketch — implementation gated
+
+Java doesn't have a codegen layer yet. Per roadmap H4: "TS codegen Java target —
+2-3 wk." When that ships, this FR ships alongside as one of the codegen targets
+the Java codegen produces.
+
+## Design (when ready)
+
+### Jackson alignment
+
+Jackson is the de facto JSON-parsing library in the Java ecosystem. Spring Boot
+defaults to it; most LLM-Java libraries use it. The generated parser uses
+`ObjectMapper.readValue(text, Xxx.class)` — the canonical Jackson call.
+
+The Java codegen layer (per H4) will already need to make Jackson-vs-Gson-vs-other
+decisions for entity and payload-VO emission; the output parser inherits that
+choice.
+
+### No dual API
+
+Java doesn't have an idiomatic dual-API precedent like .NET's `Parse`/`TryParse`.
+Jackson throws `JsonProcessingException`; callers wrap in try/catch. Matching the
+ecosystem norm, the generated parser is single-API throw-only.
+
+If a Java adopter wants a Result-style API, they wrap the call themselves —
+likely using Vavr's `Try<T>` or a hand-rolled `Result<T>` type. The codegen
+doesn't bless one.
+
+### Field-type → Jackson-annotation mapping
+
+The payload-VO (POJO emitted by the Java codegen) carries Jackson annotations:
+
+| Field subtype | Jackson / POJO shape |
+|---|---|
+| `field.string` | `String` (with `@JsonProperty` for camelCase if needed) |
+| `field.int` / `field.long` / `field.short` / `field.byte` | matching primitive or boxed |
+| `field.double` / `field.float` | matching primitive or boxed |
+| `field.boolean` | `boolean` |
+| `field.date` / `field.time` / `field.timestamp` | `java.time.{LocalDate, LocalTime, Instant}` |
+| `field.enum` | Java `enum` |
+| `field.currency` | `long` (minor units) |
+| `field.object` | nested POJO |
+| `isArray: true` | `List<...>` |
+
+## Out of scope
+
+Same exclusions as FR6 parent. Plus: no Java implementation until the codegen
+layer ships (gated on H4).
+
+## Open questions
+
+When implementation time comes:
+
+1. Jackson vs Gson vs other (presumably settled by the broader Java codegen design
+   in H4).
+2. Whether to emit a separate parser class or add a `parse` static method to the
+   POJO itself (Java conventions vary).
+3. `meta verify` story for Java — whether to ship a Java CLI extension or rely on
+   the TS CLI (TS CLI can verify Java metadata since metadata is language-agnostic).