feat(issue-lifecycle): add platform type to IssueType Zod schema #27

Merged

stack72 merged 1 commit from feat/issue-lifecycle-platform-type into main 2026-06-03 13:12:59 +00:00

Conversation 2 Commits 1 Files changed 2 +2 -2

stack72 commented 2026-06-03 12:50:22 +00:00

Owner

Copy link

Summary

• Add "platform" to the IssueType Zod enum in extensions/models/_lib/schemas.ts so the issue-lifecycle model accepts the new admin-only platform issue type at runtime
• Update the corresponding type annotation in extensions/models/issue_lifecycle.ts

Test plan

• Zod enum is additive — no breaking changes
• Type annotation matches the Zod enum

## Summary - Add `"platform"` to the `IssueType` Zod enum in `extensions/models/_lib/schemas.ts` so the issue-lifecycle model accepts the new admin-only platform issue type at runtime - Update the corresponding type annotation in `extensions/models/issue_lifecycle.ts` ## Test plan - [x] Zod enum is additive — no breaking changes - [x] Type annotation matches the Zod enum

stack72 added 1 commit 2026-06-03 12:50:23 +00:00

feat(issue-lifecycle): add platform type to IssueType Zod schema ... 5393d758e5

Add the new admin-only platform issue type to the IssueType enum so the
lifecycle model accepts platform issues at runtime.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

stack72 commented 2026-06-03 12:57:55 +00:00

Author

Owner

Copy link

Adversarial Review

Scope: Only two non-generated files were changed:

• issue-lifecycle/extensions/models/_lib/schemas.ts (line 93)
• issue-lifecycle/extensions/models/issue_lifecycle.ts (line 559)

All other changed files are under model/ and are auto-generated — skipped per project rules.

Analysis

The PR adds "platform" to the IssueType Zod enum and the corresponding TypeScript union literal in the triage tool's execute signature.

Tracing the data flow of the type field:

1. Zod validation (schemas.ts:93): IssueType enum now includes "platform" — any triage call with type: "platform" will pass validation.
2. Classification resource (schemas.ts:127): ClassificationSchema.type references the same IssueType — consistent.
3. Execute handler (issue_lifecycle.ts:586): args.type is written to the classification resource as data — no branching on specific type values.
4. State transition (issue_lifecycle.ts:598): Phase goes to "classified" regardless of type — no issue.
5. SwampClub API (swamp_club.ts:191-192): updateType() sends the type as a string to the API via patchIssue() — no local validation beyond the Zod enum.
6. Lifecycle entry (issue_lifecycle.ts:621-635): Type is interpolated into a summary string and included in the payload — no conditional logic.

There are no switch statements, if chains, or any other conditional branching on IssueType values in the codebase. The type flows through as opaque data. Adding a new enum value is safe.

Checked for omissions:

• swamp_club.ts:126 casts issue.type ?? "feature" as IssueType — this is in unchanged code and works correctly; issues already typed as "platform" on the server will now be accepted by the Zod schema rather than failing validation at runtime. This is actually a fix for what would have been a latent runtime error if the server ever returned type: "platform".

Verdict

PASS — Minimal, consistent change. The new "platform" enum value is properly propagated to both the Zod schema and the TypeScript type annotation. No downstream logic depends on exhaustive matching of issue types, so no missing cases are introduced.

## Adversarial Review **Scope:** Only two non-generated files were changed: - `issue-lifecycle/extensions/models/_lib/schemas.ts` (line 93) - `issue-lifecycle/extensions/models/issue_lifecycle.ts` (line 559) All other changed files are under `model/` and are auto-generated — skipped per project rules. ### Analysis The PR adds `"platform"` to the `IssueType` Zod enum and the corresponding TypeScript union literal in the `triage` tool's `execute` signature. **Tracing the data flow of the `type` field:** 1. **Zod validation** (`schemas.ts:93`): `IssueType` enum now includes `"platform"` — any triage call with `type: "platform"` will pass validation. 2. **Classification resource** (`schemas.ts:127`): `ClassificationSchema.type` references the same `IssueType` — consistent. 3. **Execute handler** (`issue_lifecycle.ts:586`): `args.type` is written to the `classification` resource as data — no branching on specific type values. 4. **State transition** (`issue_lifecycle.ts:598`): Phase goes to `"classified"` regardless of type — no issue. 5. **SwampClub API** (`swamp_club.ts:191-192`): `updateType()` sends the type as a string to the API via `patchIssue()` — no local validation beyond the Zod enum. 6. **Lifecycle entry** (`issue_lifecycle.ts:621-635`): Type is interpolated into a summary string and included in the payload — no conditional logic. There are no `switch` statements, `if` chains, or any other conditional branching on `IssueType` values in the codebase. The type flows through as opaque data. Adding a new enum value is safe. **Checked for omissions:** - `swamp_club.ts:126` casts `issue.type ?? "feature"` as `IssueType` — this is in unchanged code and works correctly; issues already typed as `"platform"` on the server will now be accepted by the Zod schema rather than failing validation at runtime. This is actually a fix for what would have been a latent runtime error if the server ever returned `type: "platform"`. ### Verdict **PASS** — Minimal, consistent change. The new `"platform"` enum value is properly propagated to both the Zod schema and the TypeScript type annotation. No downstream logic depends on exhaustive matching of issue types, so no missing cases are introduced.

stack72 commented 2026-06-03 13:02:52 +00:00

Author

Owner

Copy link

Code Review

Blocking Issues

1. PR will revert recent model regeneration (needs rebase) — This PR was branched before a8676ee9 ("chore: regenerate models from upstream schemas #24") landed on main. Merging as-is would:

   • Delete the entire model/aws/resiliencehubv2/ service (policy, service, system models + manifest) that was added in #24
   • Delete model/aws/bedrockagentcore/extensions/models/payment_connector.ts
   • Downgrade published versions of bedrockagentcore, connectcampaignsv2, elasticache, rtbfabric, sagemaker, and multiple GCP services back to pre-#24 versions
   • Revert schema changes to gateway.ts and gateway_target.ts (e.g., re-adding AUTHENTICATE_ONLY to AuthorizerType, removing ProtocolType)

   The fix is to rebase this branch onto the current main before merging. The only intended diff should be the two lines changed in issue-lifecycle/.

2. Model files have schema changes without codegen/ changes — Per CLAUDE.md: "Never hand-edit files under model/. Fix the codegen pipeline in codegen/<provider>/ and regenerate instead." The review criteria state that model files changing beyond version/upgrade entries without corresponding codegen/ changes is a blocking issue. No codegen/ files are modified in this PR, yet 57 model files have substantive schema changes. (This is a consequence of issue #1 — the rebase will eliminate these diff hunks entirely once the PR is brought up to date with main.)

3. IssueType schema change is missing a model version bump and upgrade entry — issue_lifecycle.ts keeps version: "2026.05.21.1" unchanged despite the schema now accepting a new "platform" value. CLAUDE.md states CI auto-publishes when manifest.yaml changes with a newer version. Without bumping the model version (and correspondingly updating issue-lifecycle/manifest.yaml), the change will not be published to the registry and deployed instances will continue to reject type: "platform" at runtime. A new version (e.g., "2026.06.03.1") and a corresponding upgrade entry in the upgrades array are needed.

Suggestions

1. Avoid duplicating IssueType as a manual union — The execute parameter at issue_lifecycle.ts:559 spells out type: "bug" | "feature" | "platform" | "security" manually. This PR demonstrates the maintenance burden: both schemas.ts and issue_lifecycle.ts had to be updated. Changing the annotation to use IssueType (or z.infer<typeof IssueType>) would make future additions automatic and eliminate the risk of them drifting apart.

## Code Review ### Blocking Issues 1. **PR will revert recent model regeneration (needs rebase)** — This PR was branched before `a8676ee9` ("chore: regenerate models from upstream schemas #24") landed on main. Merging as-is would: - Delete the entire `model/aws/resiliencehubv2/` service (policy, service, system models + manifest) that was added in #24 - Delete `model/aws/bedrockagentcore/extensions/models/payment_connector.ts` - Downgrade published versions of `bedrockagentcore`, `connectcampaignsv2`, `elasticache`, `rtbfabric`, `sagemaker`, and multiple GCP services back to pre-#24 versions - Revert schema changes to `gateway.ts` and `gateway_target.ts` (e.g., re-adding `AUTHENTICATE_ONLY` to `AuthorizerType`, removing `ProtocolType`) The fix is to rebase this branch onto the current `main` before merging. The only intended diff should be the two lines changed in `issue-lifecycle/`. 2. **Model files have schema changes without codegen/ changes** — Per CLAUDE.md: *"Never hand-edit files under `model/`. Fix the codegen pipeline in `codegen/<provider>/` and regenerate instead."* The review criteria state that model files changing beyond version/upgrade entries without corresponding `codegen/` changes is a blocking issue. No `codegen/` files are modified in this PR, yet 57 model files have substantive schema changes. (This is a consequence of issue #1 — the rebase will eliminate these diff hunks entirely once the PR is brought up to date with main.) 3. **IssueType schema change is missing a model version bump and upgrade entry** — `issue_lifecycle.ts` keeps `version: "2026.05.21.1"` unchanged despite the schema now accepting a new `"platform"` value. CLAUDE.md states CI auto-publishes when `manifest.yaml` changes with a newer version. Without bumping the model version (and correspondingly updating `issue-lifecycle/manifest.yaml`), the change will not be published to the registry and deployed instances will continue to reject `type: "platform"` at runtime. A new version (e.g., `"2026.06.03.1"`) and a corresponding upgrade entry in the `upgrades` array are needed. ### Suggestions 1. **Avoid duplicating `IssueType` as a manual union** — The `execute` parameter at `issue_lifecycle.ts:559` spells out `type: "bug" | "feature" | "platform" | "security"` manually. This PR demonstrates the maintenance burden: both `schemas.ts` and `issue_lifecycle.ts` had to be updated. Changing the annotation to use `IssueType` (or `z.infer<typeof IssueType>`) would make future additions automatic and eliminate the risk of them drifting apart.

stack72 merged commit 0bb7313fa5 into main 2026-06-03 13:12:59 +00:00

stack72 deleted branch feat/issue-lifecycle-platform-type 2026-06-03 13:12:59 +00:00

stack72 referenced this pull request from a commit 2026-06-03 13:12:59 +00:00

feat(issue-lifecycle): add platform type to IssueType Zod schema (#27)

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

swamp-club/swamp-extensions!27

No description provided.