silvermoon 0.3.0-rc.2 → 0.4.0

package/dist/src/foundation/tui/tui.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"tui.js","sourceRoot":"","sources":["../../../../src/foundation/tui/tui.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,iBAAiB,EAAE,MAAM,eAAe,CAAC;AAElD,OAAO,EAAE,KAAK,EAAE,MAAM,WAAW,CAAC;AAClC,OAAO,EACL,UAAU,EACV,WAAW,EACX,WAAW,EACX,qBAAqB,GACtB,MAAM,gBAAgB,CAAC;AACxB,OAAO,EAAE,aAAa,EAAE,SAAS,EAAE,OAAO,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,OAAO,CAAC;AAC5E,OAAO,EAAE,QAAQ,EAAE,MAAM,QAAQ,CAAC;AAElC,OAAO,EAAE,aAAa,EAAE,MAAM,qBAAqB,CAAC;AACpD,OAAO,EAAE,iBAAiB,EAAE,MAAM,YAAY,CAAC;AAM/C,MAAM,uBAAuB,GAAG,IAAI,CAAC;AACrC,MAAM,aAAa,GAAG,mDAAmD,CAAC;AAC1E,MAAM,aAAa,GAAG,SAAS,CAAC;AAChC,MAAM,aAAa,GAAG,SAAS,CAAC;AAEhC,SAAS,cAAc,CAAC,OAAe,EAAE,IAAuB,EAAE,OAA2C;IAC3G,OAAO,aAAa,CAAC,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE;QAC3C,UAAU,EAAE,EAAE,SAAS,EAAE,mBAAmB,EAAE;KAC/C,CAAC,CAAC;AACL,CAAC;AAED,MAAM,UAAU,eAAe,CAAC,MAA+B;IAC7D,IAAI,MAAM,KAAK,IAAI;QAAE,OAAO,SAAS,CAAC;IACtC,IAAI,MAAM,CAAC,IAAI,KAAK,SAAS;QAAE,OAAO,aAAa,CAAC;IACpD,IAAI,MAAM,CAAC,IAAI,KAAK,SAAS;QAAE,OAAO,aAAa,CAAC;IACpD,MAAM,IAAI,KAAK,CAAC,iCAAiC,MAAM,CAAC,IAAI,EAAE,CAAC,CAAC;AAClE,CAAC;AAED,MAAM,UAAU,oBAAoB,CAClC,IAAY,EACZ,QAIgC,cAAc,EAC9C,UAAU,GAAG,OAAO,CAAC,GAAG,CAAC,UAAU;IAEnC,IAAI,CAAC,UAAU;QAAE,OAAO,EAAE,EAAE,EAAE,KAAK,EAAE,MAAM,EAAE,2BAA2B,EAAE,CAAC;IAC3E,MAAM,MAAM,GAAG;QACb,iCAAiC;QACjC,wEAAwE;QACxE,oCAAoC;QACpC,6BAA6B;KAC9B,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;IACb,MAAM,MAAM,GAAG,KAAK,CAAC,KAAK,CAAC,IAAI,CAC7B,UAAU,EAAE,UAAU,EAAE,mBAAmB,EAAE,MAAM,EAAE,gBAAgB,CACtE,EAAE;QACD,YAAY,EAAE,iBAAiB,EAAE,UAAU,EAAE,MAAM;KACpD,EAAE;QACD,QAAQ,EAAE,MAAM;QAChB,KAAK,EAAE,MAAM,CAAC,IAAI,CAAC,IAAI,EAAE,MAAM,CAAC;QAChC,OAAO,EAAE,IAAI;QACb,WAAW,EAAE,IAAI;KAClB,CAAC,CAAC;IACH,IAAI,MAAM,CAAC,KAAK;QAAE,OAAO,EAAE,EAAE,EAAE,KAAK,EAAE,MAAM,EAAE,MAAM,CAAC,KAAK,CAAC,OAAO,EAAE,CAAC;IACrE,IAAI,MAAM,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QACxB,OAAO;YACL,EAAE,EAAE,KAAK;YACT,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,IAAI,EAAE,CAAC,KAAK,CAAC,OAAO,EAAE,CAAC,CAAC,CAAC,CAAC,CAAC;mBAC7C,iCAAiC,MAAM,CAAC,MAAM,EAAE;SACtD,CAAC;IACJ,CAAC;IACD,OAAO,EAAE,EAAE,EAAE,IAAI,EAAE,CAAC;AACtB,CAAC;AAYD,MAAM,UAAU,gBAAgB,CAAC,QAA2B,EAAE,EAC5D,MAAM,GAAG,OAAO,CAAC,MAAM,EACvB,QAAQ,GAAG,OAAO,CAAC,QAAQ,EAC3B,gBAAgB,GAAG,oBAAoB,MAKrC,EAAE;IACJ,MAAM,IAAI,GAAG,QAAQ,CAAC,YAAY,EAAE,EAAE,eAAe,EAAE,CAAC;IACxD,IAAI,CAAC,IAAI;QAAE,OAAO,EAAE,OAAO,EAAE,mBAAmB,EAAE,IAAI,EAAE,SAAS,EAAE,CAAC;IACpE,IAAI,QAAQ,CAAC,oBAAoB,CAAC,IAAI,CAAC,EAAE,CAAC;QACxC,OAAO,EAAE,OAAO,EAAE,iCAAiC,EAAE,IAAI,EAAE,SAAS,EAAE,CAAC;IACzE,CAAC;IACD,IAAI,QAAQ,KAAK,OAAO,IAAI,MAAM,KAAK,OAAO,CAAC,MAAM,EAAE,CAAC;QACtD,MAAM,MAAM,GAAG,gBAAgB,CAAC,IAAI,CAAC,CAAC;QACtC,OAAO,MAAM,CAAC,EAAE;YACd,CAAC,CAAC,EAAE,OAAO,EAAE,6BAA6B,EAAE,IAAI,EAAE,SAAS,EAAE;YAC7D,CAAC,CAAC,EAAE,OAAO,EAAE,gBAAgB,MAAM,CAAC,MAAM,EAAE,EAAE,IAAI,EAAE,SAAS,EAAE,CAAC;IACpE,CAAC;IACD,OAAO,EAAE,OAAO,EAAE,0BAA0B,EAAE,IAAI,EAAE,SAAS,EAAE,CAAC;AAClE,CAAC;AAED,SAAS,cAAc,CAAC,EACtB,OAAO,EACP,MAAM,GAC0C;IAChD,MAAM,QAAQ,GAAG,WAAW,EAAE,CAAC;IAC/B,MAAM,EAAE,MAAM,EAAE,KAAK,EAAE,GAAG,qBAAqB,EAAE,CAAC;IAClD,MAAM,CAAC,UAAU,EAAE,aAAa,CAAC,GAAG,QAAQ,CAAoB,IAAI,CAAC,CAAC;IACtE,MAAM,iBAAiB,GAAG,MAAM,CAAwB,IAAI,CAAC,CAAC;IAC9D,MAAM,YAAY,GAAG,IAAI,CAAC,GAAG,CAAC,CAAC,EAAE,KAAK,GAAG,CAAC,CAAC,CAAC;IAC5C,MAAM,MAAM,GAAG,OAAO,CACpB,GAAG,EAAE,CAAC,iBAAiB,CAAC,OAAO,EAAE,YAAY,CAAC,EAC9C,CAAC,OAAO,EAAE,YAAY,CAAC,CACxB,CAAC;IAEF,SAAS,CAAC,GAAG,EAAE,CAAC,GAAG,EAAE;QACnB,IAAI,iBAAiB,CAAC,OAAO,KAAK,IAAI;YAAE,YAAY,CAAC,iBAAiB,CAAC,OAAO,CAAC,CAAC;IAClF,CAAC,EAAE,EAAE,CAAC,CAAC;IAEP,WAAW,CAAC,CAAC,GAAG,EAAE,EAAE;QAClB,IAAI,GAAG,CAAC,IAAI,KAAK,GAAG,IAAI,GAAG,CAAC,IAAI,KAAK,QAAQ;YAAE,QAAQ,CAAC,OAAO,EAAE,CAAC;QAClE,IAAI,GAAG,CAAC,IAAI,KAAK,GAAG,EAAE,CAAC;YACrB,IAAI,iBAAiB,CAAC,OAAO,KAAK,IAAI;gBAAE,YAAY,CAAC,iBAAiB,CAAC,OAAO,CAAC,CAAC;YAChF,aAAa,CAAC,gBAAgB,CAAC,QAAQ,EAAE,EAAE,MAAM,EAAE,CAAC,CAAC,CAAC;YACtD,iBAAiB,CAAC,OAAO,GAAG,UAAU,CAAC,GAAG,EAAE;gBAC1C,aAAa,CAAC,IAAI,CAAC,CAAC;gBACpB,iBAAiB,CAAC,OAAO,GAAG,IAAI,CAAC;YACnC,CAAC,EAAE,uBAAuB,CAAC,CAAC;QAC9B,CAAC;IACH,CAAC,CAAC,CAAC;IAEH,OAAO,aAAa,CAClB,KAAK,EACL;QACE,aAAa,EAAE,QAAQ;QACvB,MAAM;QACN,KAAK;KACN,EACD,aAAa,CACX,KAAK,EACL;QACE,eAAe,EAAE,SAAS;QAC1B,UAAU,EAAE,CAAC;QACb,QAAQ,EAAE,CAAC;QACX,KAAK,EAAE,MAAM;KACd,EACD,aAAa,CAAC,MAAM,EAAE,EAAE,EAAE,EAAE,SAAS,EAAE,EAAE,YAAY,CAAC,EACtD,aAAa,CACX,MAAM,EACN;QACE,EAAE,EAAE,eAAe,CAAC,UAAU,CAAC;QAC/B,MAAM,EAAE,CAAC;QACT,QAAQ,EAAE,IAAI;QACd,KAAK,EAAE,MAAM;QACb,QAAQ,EAAE,MAAM;KACjB,EACD,UAAU,CAAC,CAAC,CAAC,KAAK,UAAU,CAAC,OAAO,EAAE,CAAC,CAAC,CAAC,aAAa,CACvD,CACF,EACD,aAAa,CACX,WAAW,EACX;QACE,QAAQ,EAAE,CAAC;QACX,UAAU,EAAE,CAAC;QACb,OAAO,EAAE,IAAI;QACb,KAAK,EAAE,MAAM;KACd,EACD,aAAa,CACX,KAAK,EACL;QACE,aAAa,EAAE,QAAQ;QACvB,QAAQ,EAAE,CAAC;QACX,QAAQ,EAAE,CAAC;QACX,KAAK,EAAE,YAAY;KACpB,EACD,GAAG,MAAM,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,KAAK,EAAE,EAAE,CAC7B,KAAK,CAAC,IAAI,KAAK,UAAU;QACvB,CAAC,CAAC,aAAa,CAAC,QAAQ,EAAE,EAAE,GAAG,EAAE,KAAK,EAAE,OAAO,EAAE,KAAK,CAAC,OAAO,EAAE,CAAC;QACjE,CAAC,CAAC,aAAa,CACb,KAAK,EACL,EAAE,GAAG,EAAE,KAAK,EAAE,aAAa,EAAE,QAAQ,EAAE,YAAY,EAAE,CAAC,EAAE,KAAK,EAAE,MAAM,EAAE,EACvE,GAAG,KAAK,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,SAAS,EAAE,EAAE,CACrC,aAAa,CAAC,MAAM,EAAE;YACpB,GAAG,EAAE,SAAS;YACd,EAAE,EAAE,SAAS,KAAK,CAAC,CAAC,CAAC,CAAC,SAAS,CAAC,CAAC,CAAC,SAAS;YAC3C,KAAK,EAAE,KAAK,CAAC,KAAK;YAClB,QAAQ,EAAE,MAAM;SACjB,EAAE,IAAI,CAAC,CACT,CACF,CACJ,CACF,CACF,CACF,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,eAAe,CAAC,MAA0B,EAAE,QAAQ,GAAG,OAAO,CAAC,QAAQ;IACrF,IAAI,QAAQ,KAAK,OAAO;QAAE,OAAO,MAAM,CAAC;IAExC,6EAA6E;IAC7E,yEAAyE;IACzE,OAAO,IAAI,KAAK,CAAC,MAAM,EAAE;QACvB,GAAG,CAAC,MAAM,EAAE,QAAQ,EAAE,QAAQ;YAC5B,MAAM,KAAK,GAAG,OAAO,CAAC,GAAG,CAAC,MAAM,EAAE,QAAQ,EAAE,QAAQ,CAAC,CAAC;YACtD,OAAO,OAAO,KAAK,KAAK,UAAU,CAAC,CAAC,CAAC,KAAK,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,KAAK,CAAC;QAClE,CAAC;KACF,CAAC,CAAC;AACL,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,iBAAiB,CACrC,OAAe,EACf,EAAE,KAAK,EAAE,MAAM,EAA4D;IAE3E,IAAI,QAAiC,CAAC;IACtC,IAAI,CAAC;QACH,QAAQ,GAAG,MAAM,iBAAiB,CAAC;YACjC,eAAe,EAAE,IAAI;YACrB,WAAW,EAAE,IAAI;YACjB,UAAU,EAAE,kBAAkB;YAC9B,KAAK;YACL,MAAM,EAAE,eAAe,CAAC,MAAM,CAAC;SAChC,CAAC,CAAC;QACH,QAAQ,CAAC,gBAAgB,CAAC,YAAY,CAAC,CAAC;QACxC,UAAU,CAAC,QAAQ,CAAC,CAAC,MAAM,CAAC,aAAa,CAAC,cAAc,EAAE,EAAE,OAAO,EAAE,MAAM,EAAE,CAAC,CAAC,CAAC;IAClF,CAAC;IAAC,OAAO,MAAM,EAAE,CAAC;QAChB,QAAQ,EAAE,OAAO,EAAE,CAAC;QACpB,MAAM,MAAM,CAAC;IACf,CAAC;AACH,CAAC"}

package/dist/src/index.d.ts

@@ -0,0 +1,17 @@
+export { checkRepository } from "./business/index.ts";
+export { ACTIVE_IDEA_STATES, deriveIdeaState, IDEA_STATES, isValidUlid, parseIdeaStatus, serializeIdeaStatus, validateIdeaStatus } from "./foundation/idea-model/index.ts";
+export { IDEA_EVENT_TYPES, EVENT_PERMISSIONS, IdeaEventFormatError, checkEventChange, eventsFromStatus, initialEventState, parseIdeaEvents, reduceIdeaEvent, replayIdeaEvents, serializeIdeaEvent, serializeIdeaEvents, validateIdeaEvent } from "./foundation/event-codec/index.ts";
+export { eventCommand } from "./business/index.ts";
+export { extractIdeaTitle, ideaCreatedAt, ideaInventoryItem, normalizeIdeaQuery, queryIdeaInventory } from "./foundation/idea-query/index.ts";
+export { listIdeas } from "./business/index.ts";
+export { createIdea, generateUlid } from "./business/index.ts";
+export { inspectAdoption, SILVERMOON_VERSION } from "./foundation/skill-registration/index.ts";
+export { findSchemaMigrationPath, loadSchemaCapabilityManifest } from "./foundation/schema-capability/index.ts";
+export type { SchemaCapabilityManifest, SchemaMigrationCapability } from "./foundation/schema-capability/index.ts";
+export { CommandRun, DOMAIN_MESSAGE_SCHEMA_VERSION, DomainInvariantError, driveCommand, initialInternalObservation, projectActions, projectIntention, projectPublicObservation, projectReport, reduceObservation, replayObservation } from "./foundation/command-message/index.ts";
+export { renderResponse } from "./foundation/renderer/index.ts";
+export { respond } from "./foundation/report/index.ts";
+export { TRACE_SCHEMA_VERSION } from "./foundation/trace/index.ts";
+export { whatsNext } from "./business/index.ts";
+export { IMPLEMENTED_SCHEMA_MIGRATIONS, runSchemaMigration } from "./business/index.ts";
+//# sourceMappingURL=index.d.ts.map

package/dist/src/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,eAAe,EAAE,MAAM,qBAAqB,CAAC;AAEtD,OAAO,EAAE,kBAAkB,EAAE,eAAe,EAAE,WAAW,EAAE,WAAW,EAAE,eAAe,EAAE,mBAAmB,EAAE,kBAAkB,EAAE,MAAM,kCAAkC,CAAC;AAC3K,OAAO,EAAE,gBAAgB,EAAE,iBAAiB,EAAE,oBAAoB,EAAE,gBAAgB,EAAE,gBAAgB,EAAE,iBAAiB,EAAE,eAAe,EAAE,eAAe,EAAE,gBAAgB,EAAE,kBAAkB,EAAE,mBAAmB,EAAE,iBAAiB,EAAE,MAAM,mCAAmC,CAAC;AACrR,OAAO,EAAE,YAAY,EAAE,MAAM,qBAAqB,CAAC;AACnD,OAAO,EAAE,gBAAgB,EAAE,aAAa,EAAE,iBAAiB,EAAE,kBAAkB,EAAE,kBAAkB,EAAE,MAAM,kCAAkC,CAAC;AAC9I,OAAO,EAAE,SAAS,EAAE,MAAM,qBAAqB,CAAC;AAChD,OAAO,EAAE,UAAU,EAAE,YAAY,EAAE,MAAM,qBAAqB,CAAC;AAC/D,OAAO,EAAE,eAAe,EAAE,kBAAkB,EAAE,MAAM,0CAA0C,CAAC;AAC/F,OAAO,EAAE,uBAAuB,EAAE,4BAA4B,EAAE,MAAM,yCAAyC,CAAC;AAChH,YAAY,EAAE,wBAAwB,EAAE,yBAAyB,EAAE,MAAM,yCAAyC,CAAC;AACnH,OAAO,EAAE,UAAU,EAAE,6BAA6B,EAAE,oBAAoB,EAAE,YAAY,EAAE,0BAA0B,EAAE,cAAc,EAAE,gBAAgB,EAAE,wBAAwB,EAAE,aAAa,EAAE,iBAAiB,EAAE,iBAAiB,EAAE,MAAM,uCAAuC,CAAC;AACnR,OAAO,EAAE,cAAc,EAAE,MAAM,gCAAgC,CAAC;AAChE,OAAO,EAAE,OAAO,EAAE,MAAM,8BAA8B,CAAC;AACvD,OAAO,EAAE,oBAAoB,EAAE,MAAM,6BAA6B,CAAC;AACnE,OAAO,EAAE,SAAS,EAAE,MAAM,qBAAqB,CAAC;AAChD,OAAO,EAAE,6BAA6B,EAAE,kBAAkB,EAAE,MAAM,qBAAqB,CAAC"}

package/dist/src/index.js

@@ -0,0 +1,16 @@
+export { checkRepository } from "./business/index.js";
+export { ACTIVE_IDEA_STATES, deriveIdeaState, IDEA_STATES, isValidUlid, parseIdeaStatus, serializeIdeaStatus, validateIdeaStatus } from "./foundation/idea-model/index.js";
+export { IDEA_EVENT_TYPES, EVENT_PERMISSIONS, IdeaEventFormatError, checkEventChange, eventsFromStatus, initialEventState, parseIdeaEvents, reduceIdeaEvent, replayIdeaEvents, serializeIdeaEvent, serializeIdeaEvents, validateIdeaEvent } from "./foundation/event-codec/index.js";
+export { eventCommand } from "./business/index.js";
+export { extractIdeaTitle, ideaCreatedAt, ideaInventoryItem, normalizeIdeaQuery, queryIdeaInventory } from "./foundation/idea-query/index.js";
+export { listIdeas } from "./business/index.js";
+export { createIdea, generateUlid } from "./business/index.js";
+export { inspectAdoption, SILVERMOON_VERSION } from "./foundation/skill-registration/index.js";
+export { findSchemaMigrationPath, loadSchemaCapabilityManifest } from "./foundation/schema-capability/index.js";
+export { CommandRun, DOMAIN_MESSAGE_SCHEMA_VERSION, DomainInvariantError, driveCommand, initialInternalObservation, projectActions, projectIntention, projectPublicObservation, projectReport, reduceObservation, replayObservation } from "./foundation/command-message/index.js";
+export { renderResponse } from "./foundation/renderer/index.js";
+export { respond } from "./foundation/report/index.js";
+export { TRACE_SCHEMA_VERSION } from "./foundation/trace/index.js";
+export { whatsNext } from "./business/index.js";
+export { IMPLEMENTED_SCHEMA_MIGRATIONS, runSchemaMigration } from "./business/index.js";
+//# sourceMappingURL=index.js.map

package/dist/src/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,eAAe,EAAE,MAAM,qBAAqB,CAAC;AAEtD,OAAO,EAAE,kBAAkB,EAAE,eAAe,EAAE,WAAW,EAAE,WAAW,EAAE,eAAe,EAAE,mBAAmB,EAAE,kBAAkB,EAAE,MAAM,kCAAkC,CAAC;AAC3K,OAAO,EAAE,gBAAgB,EAAE,iBAAiB,EAAE,oBAAoB,EAAE,gBAAgB,EAAE,gBAAgB,EAAE,iBAAiB,EAAE,eAAe,EAAE,eAAe,EAAE,gBAAgB,EAAE,kBAAkB,EAAE,mBAAmB,EAAE,iBAAiB,EAAE,MAAM,mCAAmC,CAAC;AACrR,OAAO,EAAE,YAAY,EAAE,MAAM,qBAAqB,CAAC;AACnD,OAAO,EAAE,gBAAgB,EAAE,aAAa,EAAE,iBAAiB,EAAE,kBAAkB,EAAE,kBAAkB,EAAE,MAAM,kCAAkC,CAAC;AAC9I,OAAO,EAAE,SAAS,EAAE,MAAM,qBAAqB,CAAC;AAChD,OAAO,EAAE,UAAU,EAAE,YAAY,EAAE,MAAM,qBAAqB,CAAC;AAC/D,OAAO,EAAE,eAAe,EAAE,kBAAkB,EAAE,MAAM,0CAA0C,CAAC;AAC/F,OAAO,EAAE,uBAAuB,EAAE,4BAA4B,EAAE,MAAM,yCAAyC,CAAC;AAEhH,OAAO,EAAE,UAAU,EAAE,6BAA6B,EAAE,oBAAoB,EAAE,YAAY,EAAE,0BAA0B,EAAE,cAAc,EAAE,gBAAgB,EAAE,wBAAwB,EAAE,aAAa,EAAE,iBAAiB,EAAE,iBAAiB,EAAE,MAAM,uCAAuC,CAAC;AACnR,OAAO,EAAE,cAAc,EAAE,MAAM,gCAAgC,CAAC;AAChE,OAAO,EAAE,OAAO,EAAE,MAAM,8BAA8B,CAAC;AACvD,OAAO,EAAE,oBAAoB,EAAE,MAAM,6BAA6B,CAAC;AACnE,OAAO,EAAE,SAAS,EAAE,MAAM,qBAAqB,CAAC;AAChD,OAAO,EAAE,6BAA6B,EAAE,kBAAkB,EAAE,MAAM,qBAAqB,CAAC"}

package/docs/core-concepts.md

@@ -8,7 +8,7 @@ repository-owned account of intent, implementation, and real-world truth.
 ### Less continuous supervision
 
 People should not have to shepherd every mechanical step. They define and
-approve the desired outcome, accept the implementation, and accept the
+accept the desired outcome, accept the implementation, and accept the
 real-world result. Between those decisions, an Agent can continue from
 repository facts and stop only when human judgment or an external result is
 required.
@@ -38,6 +38,13 @@ implementation.
 `Deployment.md` plus evidence that the implementation is true where it must
 operate.
 
+Preparation completes the Ideal contract and seeds both downstream contracts
+with lightweight first versions: at most three high-level steps and three
+observable criteria each, mirrored unchecked in `ledger.md`. These seeds expose
+feasibility before Idea acceptance, but that decision still accepts only the
+Ideal tree. Implementation and deployment phases progressively refine their
+respective seeds.
+
 The directory structure makes the relationship concrete: the Inner World
 contains the Ideal World, and the Outer World contains both. Each world is an
 opaque Git tree. Its revision therefore includes every nested world. Changing
@@ -50,16 +57,50 @@ while it refers to the exact artifacts that were reviewed.
 
 ## Decisions And Continuation
 
-Humans own four decisions: approval of the ideal, acceptance of the
-implementation, acceptance of the deployment, and abandonment. Silvermoon has
-no mutation command for these decisions and never infers them from prose,
-checklists, Git activity, or silence.
+Humans own four decisions: acceptance of the idea, acceptance of the
+implementation, acceptance of the deployment, and abandonment. Silvermoon never
+infers them from prose, checklists, Git activity, or silence. V1 records explicit
+decisions in canonical status YAML; v2 uses controlled event commands bound to
+the exact world, log and primary. A confirmation flag asserts a prior human
+decision, not authorization by itself.
 
 Agents own continuation. The project skill combines `whats-next`,
 `response.nextSteps`, the world contracts, the idea ledger, and Git facts to
 choose one safe action. The ledger is operational memory: it mirrors stable
-contract IDs and records completed work, but a checked item is not approval or
-acceptance.
+contract IDs and records completed work, but a checked item is not acceptance.
+
+Each selected v2 idea reports all three phase submissions and current control.
+An Agent-owned `submitIdeal`, `submitInner`, or `submitOuter` records that the
+exact world revision is complete without accepting it. The matching upstream
+`accept*` remains a separate human decision. Ping/pong continues to transfer
+control within a phase.
+
+Only a current-phase submission with upstream control adds `response.review`.
+That object supplies a primary-bound seed for the review index: lifecycle
+phase, decision event, exact revision, fetched primary commit, current-world
+scope, and canonical documents. Agents still inspect relevant supporting files
+and evidence before submitting. Its `presentation` object supplies the fixed
+gate labels, document labels, primary connector, and exact decision question
+from the effective content language, independently of the report's temporary
+output language. Unsupported built-in content locales carry an explicit
+fallback that the Agent must localize. JSON retains complete object IDs while
+the human-facing index uses 12-character references. The Agent adds only the
+review focus, substantive review material, and host-specific clickable local
+and immutable remote links in a completed assistant message before any later
+interactive decision.
+
+## Persistent State Events
+
+In v2 projects, each idea's `events.jsonl` file is its sole durable state
+authority. Ten business event kinds change metadata, three submitted revisions,
+three accepted revisions, or abandonment state; ping and pong carry interaction
+messages. Replay is pure; observation of real world trees is still read-only
+and separate. It projects ordered messages and unified control rather than a
+ping/pong-only last signal. No-op events are rejected. Healthy primary prefixes
+are immutable; a definitively reduction-failed base may be repaired to a fully
+valid log. Old valid facts and concurrent candidates are preserved through
+ordinary Git. See the
+[event operations contract](../skills/silvermoon/references/events.md).
 
 ## Command Event Model
 

package/docs/getting-started.md

@@ -11,44 +11,51 @@ This guide is the authoritative setup and first-use path for Silvermoon.
 
 ## Run Silvermoon And Register Its Skill
 
-Install Silvermoon independently of the target project's dependency graph, or
-invoke a chosen version temporarily:
+Install the device's single Silvermoon runtime independently of every target
+project:
 
 ```sh
 npm install --global silvermoon
 silvermoon whats-next
-# or: npx silvermoon@<version> whats-next
 ```
 
-For repositories without a root `package.json`, the setup report gives the
-exact path for the running installation. Use it to register the bundled
-canonical skill through the universal `skills` target:
+Register the global package's canonical skill in a personal discovery path.
+Omit `--copy` so updates to the global package are visible through the same
+link:
 
 ```sh
-npx skills add <path-to-running-silvermoon>/skills --skill silvermoon --agent universal --yes --copy
+npx skills add <path-to-global-silvermoon>/skills --skill silvermoon --agent universal --global --yes
 ```
 
-If the repository root contains `package.json`, Silvermoon requires valid JSON
-and an exact `devDependencies.silvermoon` value of `^<running-version>`.
-Follow all commands in the setup report in order; then register the
-project-local canonical skill:
-
-```sh
-npx skills add ./node_modules/silvermoon/skills --skill silvermoon --agent universal --yes --copy
-```
-
-Only the tracked root manifest is part of readiness; installed dependencies
-and `node_modules` are not required for snapshot checks. Silvermoon checks the
-registration at `.agents/skills/silvermoon` against its running canonical
-skill, and never mutates the manifest, package-manager files, dependencies, or
-skill registration itself. Non-npm repositories remain free of npm setup.
+The personal registration may be discovered from
+`~/.agents/skills/silvermoon` or `~/.copilot/skills/silvermoon`, depending on
+the host. Target repositories never declare Silvermoon dependencies or store a
+Silvermoon skill copy. Snapshot checks ignore `package.json`, `node_modules`,
+and repository skill paths.
+
+Dialogue commands report device readiness separately from project readiness.
+For a global installation, Silvermoon verifies that every present personal
+registration resolves to the running package's canonical skill and checks the
+npm `latest` channel. A successful latest result is reused from
+`~/.cache/silvermoon/runtime-latest.json` for less than 24 hours. An unavailable
+registry or an invalid skill link is an explicit, non-blocking device advisory;
+it never changes a project snapshot result. Snapshot-only `check` commands do
+not perform either device check.
+
+Silvermoon's own source repository is the exception: it has no Silvermoon
+self-dependency and must run `node bin/silvermoon.js` from its current checkout.
+It keeps a workspace skill for unpublished development through
+`pnpm sync:skills`; that copy is not installed into other projects, and source
+commands do not query npm for a global-runtime update. See
+[Development](./maintaining.md#development) for the source CLI and skill
+workflow.
 
 ## Configure The Shared Primary
 
 Create `.silvermoon/config.yaml`:
 
 ```yaml
-version: 1
+version: 2
 primaryRepository: https://github.com/example/repository.git
 primaryBranch: main
 preferredLanguage: en
@@ -173,25 +180,31 @@ silvermoon create-idea
 silvermoon create-idea --language zh-cn
 ```
 
-The command requires the configured primary branch and upstream plus a clean
-local worktree. It does not fetch or require local HEAD to match the remote
+The command requires a local branch whose upstream identifies the configured
+primary repository and branch, plus a clean local worktree. The local branch
+name is unrestricted. It does not fetch or require local HEAD to match the remote
 tip. When those checks pass, it creates one untracked idea scaffold with
-`Idea.md`, `Implementation.md`, `Deployment.md`, `ledger.md`, and
-`status.yaml`. If valid preparing guidance exists, the success report includes
+`Idea.md`, `Implementation.md`, `Deployment.md`, `ledger.md`, and an initially
+empty v2 `events.jsonl` file.
+If valid preparing guidance exists, the success report includes
 its snapshot-bound content. Invalid preparing guidance stops before any
 scaffold path is written. The command never stages, commits, pushes, or records
 a human decision.
 
 Replace the guidance in the `Idea.md` ideal contract with the desired outcome,
-scope, and constraints. Keep the `Implementation.md` inner implementation
-contract and `Deployment.md` real-world deployment contract placeholders
-synchronized until their lifecycle phases. Review every generated path,
-validate the complete candidate, and commit and publish the prepared idea to
-the configured primary through the repository's normal non-force publication
-path. Verify it is reachable from refreshed primary before asking the user to
-review or approve the exact reported ideal revision. If publication requires a
-pull request, wait until it reaches primary; never ask for approval of an
-unpublished local candidate. Publication does not itself approve the idea.
+scope, and constraints. Before requesting Idea acceptance, replace the
+`Implementation.md` and `Deployment.md` placeholders with lightweight first
+versions of no more than three high-level steps and three observable criteria
+each. Mirror their stable IDs and short titles in `ledger.md`, leaving every
+item unchecked. These downstream seeds establish a credible path without
+expanding the Idea decision: acceptance still covers only `Idea.md`. Review
+every generated path, validate the complete candidate, and commit and publish
+the prepared idea to the configured primary through the repository's normal
+non-force publication path. Verify it is reachable from refreshed primary
+before asking the user to review or accept the reported idea candidate. If
+publication requires a pull request, wait until it reaches primary; never ask
+for acceptance of an unpublished local candidate. Publication does not itself
+accept the idea.
 
 Then ask what comes next with the generated ULID or an exact unique alias:
 
@@ -213,22 +226,24 @@ result.
 
 ## Make Decisions Explicit
 
-Silvermoon never infers approval or acceptance. After a person explicitly
-approves the current ideal, accepts the current implementation, or accepts the
-current deployment, record the exact revision reported by `whats-next` in the
+Silvermoon never infers a human decision. After a person explicitly accepts
+the current idea, current implementation, or current deployment, record the
+exact revision reported by `whats-next` in the
 corresponding `status.yaml` field. Validate the full candidate with
 `silvermoon check --worktree`, stage it, then run `silvermoon check --staged`
 to validate the index before publishing a normal non-force commit. Default
 `check` validates committed `HEAD`, not the pending commit; only a successful
 project validation exits `0`.
 
-When requesting any approval or acceptance, include the idea's alias and ULID,
-the decision and exact world revision, plus a clickable permalink to the
-canonical world entry pinned to the published primary commit. Link to
-`Idea.md`, `Implementation.md`, or `Deployment.md` as appropriate. Do not use
-a local workspace path or a branch-floating link; if the host has no known
-permalink format, provide the primary commit and repository-relative path and
-explain the limitation.
+When requesting any acceptance, include the idea's alias and ULID,
+the decision, a 12-character revision reference, a linked 12-character primary
+reference, and one review-focus sentence. Provide both a host-clickable local
+link and an immutable primary link for substantive review files. Ideal review
+links `Idea.md` and material same-world support only; Implementation and
+Deployment reviews always link their corresponding contract plus `ledger.md`.
+Keep complete object IDs internally for exact decision recording. Never use a
+branch-floating link; if the host has no known permalink format, provide the
+primary reference and repository-relative path and explain the limitation.
 
 Continue with [Core Concepts](./core-concepts.md) before changing lifecycle
 contracts, or use [Operating Silvermoon](./operations.md) for the routine

package/docs/maintaining.md

@@ -11,11 +11,28 @@ Install the locked dependency graph:
 pnpm install --frozen-lockfile
 ```
 
+Silvermoon does not depend on its own published package. Run the current
+checkout's CLI, including uncommitted source changes:
+
+```sh
+pnpm silvermoon list-ideas --audience agent
+# Equivalent: node bin/silvermoon.js list-ideas --audience agent
+```
+
+Use this entrypoint for all repository idea and check commands, not a global
+installation or `npx silvermoon`. The source checkout is a development runtime
+and uses its synchronized workspace skill; it neither requires a
+self-dependency nor rewrites the personal skill for a published global
+installation.
+
 Use the smallest check that covers a change:
 
 ```sh
 pnpm sync:skills       # refresh the generated universal skill copy
+pnpm typecheck         # strict no-emit TypeScript validation
+pnpm build             # clean reproducible JS, declarations and maps in dist/
 pnpm check:sanity      # offline pure logic and lightweight contracts
+pnpm check:pure        # JSDoc @pure constraints and functional-core imports
 pnpm check:commit      # worktree tests plus staged metadata validation
 pnpm lint:markdown     # Markdown lint (contract tests check links)
 pnpm test              # complete unit/runtime and repository contracts
@@ -31,11 +48,11 @@ pnpm check:skills      # local consistency and external skill discovery
 
 | Scenario | Responsibility |
 | --- | --- |
-| Edit / Agent iteration | `check:sanity`: CLI syntax, pure unit tests, schema and API contracts; add change-specific tests |
+| Edit / Agent iteration | `check:sanity`: strict typecheck, clean build, CLI syntax, @pure checks, pure unit tests, schema and API contracts; add change-specific tests |
 | Before commit | `check:commit`: sanity, local contracts and Markdown, skill consistency, Git/CLI smoke, whitespace, staged Silvermoon metadata |
-| Ordinary CI | Unconditional sanity then complete unit/runtime on Ubuntu/Windows/macOS, Node 22/24; complete contracts and integration, static checks and skill discovery |
+| Ordinary CI | Triggered on pull request, daily scheduled run, or manual dispatch. Unconditional sanity then complete unit/runtime on Ubuntu/Windows/macOS, Node 22/24; complete contracts and integration, static checks and skill discovery |
 | Before delivery / release | `check` or `check:release`: every release-grade gate including package contents, installed-package E2E and external discovery |
-| After publication | The existing release workflow's `verify-npm-release.mjs`: registry identity, integrity, provenance, README and CDN |
+| After publication | The existing release workflow's `verify-npm-release.ts`: registry identity, integrity, provenance, README and CDN |
 
 `test:unit` includes `test/runtime` so moving filesystem, Git and terminal
 tests out of sanity does not remove matrix coverage. `check:quick` retains its
@@ -52,6 +69,108 @@ real Git, even only to compare pure logic with Git's behavior, belong in
 `test/runtime`, not `test/unit`. Keep their assertions and platform coverage
 when splitting mixed-cost files; never disable the sanity guard to admit them.
 
+### Functional boundaries and pure functions
+
+The [source module index](../src/README.md) describes the physical boundaries.
+Every source directory has a concise responsibility README and an `index.ts`
+containing only explicit named exports. Keep assembly and initialization in
+implementation files, never in an index.
+
+Import concrete siblings within a directory. Across directory boundaries, use
+the destination's public index, including dedicated rule/trace/TUI sub-entrypoints.
+Do not import a directory's own index from its implementation files.
+Pure callers must not load a mixed runtime facade, and the presentation facade
+must not eagerly load TUI or the Copilot SDK.
+
+### Localized what's next templates
+
+Keep command-specific, user-visible `what's next` messages under
+`src/foundation/report/templates/whats-next/`. Do not add paired English and
+Chinese long-form strings to business orchestration. The template directory
+has four distinct responsibilities:
+
+- `contract.ts` defines stable kebab-case template IDs and typed dynamic
+  parameters.
+- `en-US/` and `zh-CN/` contain matching filenames, with one `@pure`
+  default-exported logical template per file.
+- Each locale's `index.ts` registers its complete catalog; `registry.ts`
+  selects a catalog without owning wording.
+- `renderers.ts` provides statically traceable locale routing for pure callers.
+
+Every locale template file starts with this review metadata:
+
+```ts
+/**
+ * @template primary-behind
+ * @when repository.primaryRelation=behind
+ * Used after observing primary when local HEAD is behind it.
+ */
+```
+
+The `@template` value must equal the filename without `.ts`. The `@when`
+expression must be machine-readable and identical in every locale; the
+explanatory sentence uses the file's locale. These comments document entry
+conditions only and never drive runtime routing.
+
+Pass all dynamic values through the template's typed parameter object. A
+template may format an already selected terminal scenario, but it must not
+read external state, perform I/O, or choose the business route. Preserve
+message structure and wording when extracting an existing template; make
+copy changes separately so their behavior is reviewable.
+
+Adding, renaming, or removing a template requires the same change in both
+locale directories, both locale indexes, the typed contract, and the static
+renderers used by pure callers. The catalog contract test enforces filename
+symmetry, header identity, registration completeness, and unique IDs.
+Agent-facing gate output renders `response.review.presentation` as one
+explicit fenced Markdown template with a direct instruction to use it. Do not
+emit the presentation object as prose or repeat its candidate metadata in
+parallel sections.
+Run the focused template unit and contract tests, `pnpm typecheck`, and
+`pnpm check:pure`; run the relevant command integration tests whenever
+callers or wording change.
+
+Moving files also requires updating package-resource URLs, authenticated cache
+source coordinates, source tools, declarations, strict package contents and tests.
+Keep source-only maintenance tools out of installed facades and package
+contents. A schema migration declared in `schema/capabilities.json` is
+different: it must have a packaged executable and a runtime router
+implementation, and both must remain covered by the strict package contract.
+
+Keep public export assembly in `src/index.ts` and preserve the existing command
+and Agent package entrypoints. Internal use cases receive narrow sets of function
+ports; they must not call another command, import the public barrel, or depend
+on CLI/presentation. Shared repository readiness belongs outside navigation.
+
+Use JSDoc `@pure` on verified functions, retaining ordinary business names:
+
+```js
+/** @pure */
+export function selectIdea(ideas, selector) {
+  return ideas.find(({ id }) => id === selector) ?? null;
+}
+```
+
+Pure functions do not mutate their inputs or shared state, access real I/O,
+read implicit time/randomness/environment, or invoke unconfirmed effects.
+Locally owned data may be mutated. Injecting a reader or callback does not make
+a function pure. Keep `@pure` separate from bundler `@__PURE__` annotations.
+
+`pnpm check:pure` uses the existing TypeScript AST and lexical symbols to check
+annotations, rule-module dependencies, known external state, calls/callbacks,
+and direct or borrowed-alias mutations. Reviewed external functions and
+standard-library methods are explicitly listed in `bin/pure-check.ts`.
+Do not add an entire package or arbitrary method to bypass a failure.
+The checker also runs in sanity and release checks; contract tests check the
+full source dependency graph and application boundaries.
+
+This is a constraint checker, not a proof of arbitrary JavaScript purity:
+dynamic object types, reflective access, runtime monkey-patching, third-party
+internals and complex alias flows still require review. Pair it with the sanity
+I/O guard, immutable-input tests and behavioral tests. The Markdown core takes
+explicit time and local calendar facts; the public renderer alone reads the
+default clock/timezone, preserving existing local-date behavior.
+
 `check:commit` always prints its scope: tests validate the **worktree**, while
 `silvermoon check --staged` validates **staged Silvermoon metadata only**.
 With partial staging these are different candidates; a passing command does
@@ -66,10 +185,17 @@ scripts, workflows and unknown paths, requires package validation. The
 selector uses the full base/head diff and both endpoints of renames; missing
 history, malformed or empty changes conservatively require validation with
 an explicit reason. Core jobs never use path filtering. Run
-`node scripts/ci-package-risk.mjs --full` to inspect the full decision;
+`node bin/ci-package-risk.ts --full` to inspect the full decision;
 `workflow_dispatch` executes the full CI set, and local `check:release` always
 executes package/E2E regardless of the diff.
 
+The CI snapshot check requires full history and a named remote matching the
+configured primary URL exactly. Its isolated runner normalizes `origin` to
+`https://github.com/shazhou-ww/silvermoon.git` and fetches `main` before checking
+the selected commit. A checkout action's default URL spelling or shallow
+history is not sufficient event-history evidence. This setup does not change
+the selected commit or the project's primary configuration.
+
 `check:skills:local` needs no external discovery tool.
 `check:skills:discover` runs `npx skills add . --list` and can use the network;
 `check:skills` runs both in order. Missing tools and failed external checks
@@ -111,11 +237,8 @@ and proposes reviewable SHA/version updates; do not auto-merge those PRs.
 Review the upstream release and action ownership, then require the complete CI
 gate before merging.
 
-The branch ruleset depends only on the stable `Required checks` job name. That
-aggregate job fails unless package-risk selection, unit, contract, and
-integration jobs succeed, and it requires package validation to succeed when
-risk selection enables it. Keep this name and fail-closed behavior synchronized
-with `.github/rulesets/main.json`.
+The branch ruleset protects `main` against deletion and non-fast-forward
+updates. Keep its configuration synchronized with `.github/rulesets/main.json`.
 
 ## Documentation Ownership
 

package/docs/npm-package-releases.md

@@ -117,7 +117,7 @@ The [`publish-npm.yml`](../.github/workflows/publish-npm.yml) workflow then:
    dist-tag when the version was absent, allowing npm to include the
    package-level README metadata while the deterministic pack check and post-publication
    verifier guarantee the registry tarball matches the candidate bytes; and
-8. runs `verify-npm-release.mjs` until the registry is consistent or the
+8. runs `verify-npm-release.ts` until the registry is consistent or the
    bounded retry window expires.
 
 The post-publication verifier requires the exact version and dist-tag, matching
@@ -142,13 +142,13 @@ duplicate publication without replacing the existing version.
 
 Prepare release notes in the repository before creating the immutable tag.
 After the trusted-publishing workflow succeeds and its verifier proves the npm
-result, create the GitHub Release from the already-existing tag. For `0.3.0`:
+result, create the GitHub Release from the already-existing tag. For `0.4.0`:
 
 ```sh
-gh release create npm/silvermoon/v0.3.0 \
+gh release create npm/silvermoon/v0.4.0 \
   --verify-tag \
-  --title "Silvermoon 0.3.0" \
-  --notes-file .github/release-notes/0.3.0.md
+  --title "Silvermoon 0.4.0" \
+  --notes-file .github/release-notes/0.4.0.md
 ```
 
 Do not let a release command create, move, or replace the tag. The GitHub
@@ -175,13 +175,42 @@ workflow job when GitHub offers that option; the planner recognizes the
 existing version, skips `npm publish`, and performs the same complete
 verification again.
 
+### 0.4.0 one-time recovery
+
+The immutable `npm/silvermoon/v0.4.0` tag remains the failed original release
+instruction and must not be moved, deleted, or recreated. The only authorized
+recovery source is the protected `npm/silvermoon-recovery/v0.4.0` tag. Its
+commit must descend from the original release commit and be reachable from
+`origin/main`.
+
+The workflow maps the exact recovery tag to `npm/silvermoon/v0.4.0` only for
+package selection and version validation. It builds and archives the recovery
+commit itself; the tarball `gitHead`, generated README links, npm provenance
+source, post-publication verifier, and GitHub Release all use the actual
+recovery tag and commit. Do not override `GITHUB_REF`, `GITHUB_SHA`, or any
+provenance environment value.
+
+After the trusted-publishing workflow and verifier succeed, create the
+`0.4.0` GitHub Release from the recovery tag:
+
+```sh
+gh release create npm/silvermoon-recovery/v0.4.0 \
+  --verify-tag \
+  --title "Silvermoon 0.4.0" \
+  --notes-file .github/release-notes/0.4.0.md
+```
+
+This is a one-time recovery for an unpublished version, not a second general
+release key. Future source, manifest, or validation failures still require a
+new version.
+
 ## Add another package
 
 1. Give the package a committed canonical `name`, SemVer `version`, and
    `publishConfig` with `access: public` and registry
    `https://registry.npmjs.org/`.
 2. Add a fixed release-key entry to `RELEASE_PACKAGES` in
-   [`prepare-npm-release.mjs`](../scripts/prepare-npm-release.mjs). Never derive
+   [`prepare-npm-release.ts`](../bin/prepare-npm-release.ts). Never derive
    a filesystem path directly from tag text.
 3. Extend the release tests with the package selection, identity, version, and
    dist-tag cases.
@@ -189,8 +218,8 @@ verification again.
    the `npm` environment.
 5. Keep its tags under the protected `npm/<release-key>/v<semver>` convention.
 
-Run `node --test test/unit/prepare-npm-release.test.mjs
-test/integration/prepare-npm-release.test.mjs
-test/contract/npm-release.test.mjs` for focused release validation and
+Run `node --test test/unit/prepare-npm-release.test.ts
+test/integration/prepare-npm-release.test.ts
+test/contract/npm-release.test.ts` for focused release validation and
 `pnpm check` for the complete repository suite before merging the mapping
 change.