@geraldmaron/construct 1.2.1 → 1.2.2

package/templates/docs/rfcs/templates/rfc-platform.template.md

@@ -0,0 +1,72 @@
+# Platform RFC: {title}
+
+- **Date**: {YYYY-MM-DD}
+- **Author**: {name}
+- **Status**: draft | in-review | accepted | rejected | superseded
+- **Change type**: breaking | non-breaking | additive
+- **Affects**: {API | SDK | schema | event | config | permission model | protocol}
+- **Supersedes**: {RFC title or N/A}
+
+<!--
+Use this when the proposal changes a contract consumed by other systems:
+APIs, SDKs, schemas, event payloads, permission models, config shapes, or protocols.
+
+Use rfc.md instead for proposals that do not touch external contracts.
+-->
+
+## Summary
+<!-- One paragraph. What contract is changing, in what direction, and why. -->
+
+## Motivation
+<!-- What problem or limitation in the current contract drives this change? Cite evidence: consumer pain points, incidents, performance data, support load. Explain why the current interface cannot simply be extended. -->
+
+## Breaking change declaration
+<!-- Be explicit: what is breaking, what is not. List every removed, renamed, or semantically changed interface element. Omitting a breaking change here is a contract violation. -->
+
+## Proposed contract
+<!-- The new interface in full. Schemas, endpoint signatures, payload shapes, permission rules, config fields. Be precise enough that a consumer can write against this spec without asking questions. -->
+
+```mermaid
+sequenceDiagram
+  participant Consumer
+  participant Platform
+  participant Backend
+  Consumer->>Platform: contract call
+  Platform->>Backend: validate and execute
+  Backend-->>Platform: result
+  Platform-->>Consumer: response
+  Note over Platform,Backend: error path — validation failure returns typed error
+```
+
+## Backwards compatibility strategy
+<!-- How existing consumers are supported during transition. Options: versioning, dual-write, feature flags, shim layer, deprecation window. State which and why. -->
+
+## Migration guide
+<!-- Step-by-step: what a consumer must change, in what order, with examples. If migration tooling is provided, describe it. If migration is manual, estimate effort. -->
+
+## Versioning and deprecation
+<!-- Version scheme for this interface. Deprecation timeline for the old version: announcement date, sunset date, removal date. Include who owns communicating the deprecation to consumers. -->
+
+## Consumer impact analysis
+<!-- List known consumers. For each: what breaks, what changes, what stays compatible, estimated migration effort. Flag consumers that require coordinated migration. -->
+
+## Rollout plan
+<!-- How the new contract ships alongside the old one. Dual-version period, traffic migration, kill switch, removal gate. Include the observable signal that triggers each phase. -->
+
+## Operational requirements
+<!-- Observability, rate limits, error handling, fallback behavior, and admin controls required for the new contract to be supportable. -->
+
+## Tradeoffs and alternatives
+<!-- Other contract designs considered. For each: what it is, why it was not chosen. -->
+
+## Risks
+<!-- Compatibility gaps, consumer adoption risk, timing risk, coordination failure. For each: likelihood, impact, mitigation. -->
+
+## Verification
+<!-- How we confirm the migration succeeded and the old version can be safely removed. Metrics, tests, observable evidence. -->
+
+## Unresolved questions
+<!-- Genuine unknowns. Each names an owner and a decision deadline. -->
+
+## References
+<!-- Related ADRs, prior RFCs, API design guidelines, consumer runbooks, tickets. -->

package/templates/homebrew/construct.rb

@@ -8,7 +8,7 @@
 # scratch on every `v*` tag push — it downloads sha256 sidecars from the
 # GitHub Release, fills in the version and per-platform URLs/SHAs, and pushes
 # directly to the tap. The placeholder SHAs below are only used when seeding
-# the tap by hand the first time (see docs/maintenance/homebrew-tap.md).
+# the tap by hand the first time (see docs/operations/maintenance/homebrew-tap.md).
 class Construct < Formula
   desc "Deployable AI R&D operating system for coding agents — runs locally or for teams"
   homepage "https://github.com/geraldmaron/construct"

package/templates/workflows/new-feature.yml

@@ -13,28 +13,28 @@ inputs:
 
 artifacts:
   - template: prd.md
-    path: "docs/prd/${feature_name}.md"
+    path: "docs/specs/prd/${feature_name}.md"
     title: "PRD: ${feature_name}"
 
   - template: adr.md
-    path: "docs/adr/${feature_name}.md"
+    path: "docs/decisions/adr/${feature_name}.md"
     title: "ADR: ${feature_name}"
     depends_on:
-      - "docs/prd/${feature_name}.md"
+      - "docs/specs/prd/${feature_name}.md"
 
   - template: test-plan.md
     path: "docs/test-plans/${feature_name}.md"
     depends_on:
-      - "docs/adr/${feature_name}.md"
+      - "docs/decisions/adr/${feature_name}.md"
 
 beads_items:
   - type: feature
     title: "${feature_name}: spec"
-    link_to: "docs/prd/${feature_name}.md"
+    link_to: "docs/specs/prd/${feature_name}.md"
 
   - type: feature
     title: "${feature_name}: design"
-    link_to: "docs/adr/${feature_name}.md"
+    link_to: "docs/decisions/adr/${feature_name}.md"
     depends_on_prior: true
 
   - type: feature
@@ -49,5 +49,5 @@ checks:
   - name: prd-precedes-adr
     kind: file-order
     files:
-      - "docs/prd/${feature_name}.md"
-      - "docs/adr/${feature_name}.md"
+      - "docs/specs/prd/${feature_name}.md"
+      - "docs/decisions/adr/${feature_name}.md"

package/lib/intake/legacy-paths.mjs

@@ -1,5 +0,0 @@
-/**
- * lib/intake/legacy-paths.mjs — legacy intake config file path constant.
- */
-
-export const INTAKE_CONFIG_FILE = '.cx/intake-config.json';