initiative-plugin-sdk 4.1.0 → 4.1.1

package/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 Morelitea
+Copyright (c) 2026 BeyondersStudio
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/README.md

@@ -1,6 +1,6 @@
 # initiative-plugin-sdk
 
-Build a plug-in for [Initiative](https://github.com/Morelitea/initiative): a
+Build a plug-in for [Initiative](https://github.com/beyonders-studio/initiative): a
 service that reads and writes a community's content, answers Initiative's
 calls, and draws tiles on its dashboards.
 

package/manifest.contract.json

@@ -1,7 +1,7 @@
 {
   "$comment": "The Initiative plug-in contract: the vocabulary a plug-in manifest draws on and the shape it takes. Hand-authored HERE, in the initiative-plugin-sdk repository, and nowhere else. Running `npm run generate` in that repository rewrites schemas/plugin-manifest.json and src/contract.ts from this file. Initiative vendors this file to derive its validator's constants and hold its normalizer to the field inventory; the copies under initiative's backend/vendor/plugin-kit and frontend/src/contract are refreshed by backend/scripts/refresh_plugin_kit.py and are not edited there. Edit this; never the generated output. A manifest describes a plug-in's API and nothing about how a consumer PRESENTS it: there is no term here for a control, a picker, a default or a bound, because what a step looks like on somebody's canvas is that consumer's to decide and ours to stay out of.",
   "schema": {
-    "$id": "https://initiative.morels.me/schemas/plugin-manifest-v1.json",
+    "$id": "https://initiativetasks.com/schemas/plugin-manifest-v1.json",
     "title": "Initiative plug-in manifest (the 'definition' body)",
     "description": "What a plug-in declares it can do. A plug-in is a container, which names its `service` and answers Initiative's calls, or declarative, which names its `hosts` and no service, and whose endpoints, connection checks and webhook events Initiative runs itself from the requests and JSONata expressions written here; one plug-in is never both. This is the 'definition' field of the document served at /.well-known/initiative-plugin.json, NOT that whole document: a registrar also requires protocol_version, public_id and kind alongside it, and refuses a definition served bare. Generated from the platform's own validator vocabulary. A manifest that satisfies this schema is well-formed, not necessarily acceptable. Cross-references (the endpoint a widget binds, a requires term's connection, an endpoint's service prefix), the direction-specific rules on an endpoint, the features/blocks cross-check in both directions, UTF-8 byte-size caps, the rules tying a connection's flow and token to its scope and fields, what a webhooks block names, what a vendor setup writes to, whether every expression parses, what a declarative request and its steps name, and the bounds and unique ids of schedules are enforced by the platform on publish and are not expressible here."
   },

package/package.json

@@ -1,15 +1,15 @@
 {
   "name": "initiative-plugin-sdk",
-  "version": "4.1.0",
+  "version": "4.1.1",
   "description": "Build a plug-in for Initiative: one typed definition of its endpoints, hooks, schedules, widgets and listing, the server Initiative calls, the client it calls Initiative with, the CLI that builds its manifest, and declarative integrations Initiative runs from the manifest alone.",
   "license": "MIT",
   "type": "module",
   "repository": {
     "type": "git",
-    "url": "git+https://github.com/Morelitea/initiative-plugin-sdk.git"
+    "url": "git+https://github.com/beyonders-studio/initiative-plugin-sdk.git"
   },
-  "homepage": "https://github.com/Morelitea/initiative-plugin-sdk#readme",
-  "bugs": "https://github.com/Morelitea/initiative-plugin-sdk/issues",
+  "homepage": "https://github.com/beyonders-studio/initiative-plugin-sdk#readme",
+  "bugs": "https://github.com/beyonders-studio/initiative-plugin-sdk/issues",
   "keywords": [
     "initiative",
     "plugin",

package/schemas/env-contract.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "https://initiative.morelitea.com/schemas/env-contract.json",
+  "$id": "https://initiativetasks.com/schemas/env-contract.json",
   "title": "Initiative app deployment contract",
   "description": "What an app requires of whoever deploys it, published as data at env-contract.json in the app's repository root.\n\nEvery app in the set publishes one, generated from its own settings declaration and committed — because whoever reads it has a checkout, not a build. A deployment tool reads these instead of parsing each app's source, which is how a setting enforced by a validator rather than by a missing default came to be absent from the Helm chart until 2026-09-23.\n\nThe classes exist because 'required' is the distinction that misleads. An app with 131 settings and 3 mandatory ones is easy to deploy; an app that presents all 131 as configuration is not, and they look identical until someone splits them up.",
   "type": "object",

package/schemas/plugin-manifest.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "https://initiative.morels.me/schemas/plugin-manifest-v1.json",
+  "$id": "https://initiativetasks.com/schemas/plugin-manifest-v1.json",
   "title": "Initiative plug-in manifest (the 'definition' body)",
   "description": "What a plug-in declares it can do. A plug-in is a container, which names its `service` and answers Initiative's calls, or declarative, which names its `hosts` and no service, and whose endpoints, connection checks and webhook events Initiative runs itself from the requests and JSONata expressions written here; one plug-in is never both. This is the 'definition' field of the document served at /.well-known/initiative-plugin.json, NOT that whole document: a registrar also requires protocol_version, public_id and kind alongside it, and refuses a definition served bare. Generated from the platform's own validator vocabulary. A manifest that satisfies this schema is well-formed, not necessarily acceptable. Cross-references (the endpoint a widget binds, a requires term's connection, an endpoint's service prefix), the direction-specific rules on an endpoint, the features/blocks cross-check in both directions, UTF-8 byte-size caps, the rules tying a connection's flow and token to its scope and fields, what a webhooks block names, what a vendor setup writes to, whether every expression parses, what a declarative request and its steps name, and the bounds and unique ids of schedules are enforced by the platform on publish and are not expressible here.",
   "type": "object",