specrails-core 6.7.0 → 6.7.1

package/dist/agent-runtime/cli-executor.js

@@ -34,7 +34,7 @@ export function buildCliInvocation(provider, request, options = {}) {
     }
     const readOnly = requestPolicy(request).access === 'read';
     // Pin the product alias; explicit IDs remain reproducible across releases.
-    const claudeModelIds = { opus: 'claude-opus-5-5', sonnet: 'claude-sonnet-5-5', haiku: 'claude-haiku-5-5' };
+    const claudeModelIds = { opus: 'claude-opus-5-5', sonnet: 'claude-sonnet-5-5', haiku: 'claude-haiku-5-5', fable: 'claude-fable-5-1' };
     const modelId = provider === 'claude' && request.model ? claudeModelIds[request.model] ?? request.model : request.model;
     const model = modelId ? ['--model', modelId] : [];
     const extraRoots = request.allowedRoots.filter(root => root !== request.cwd);

package/dist/agent-runtime/engine/pieces/derive-change.d.ts

@@ -42,7 +42,7 @@ export declare const DERIVE_FEEDBACK_LIMIT = 8000;
 /** The deriver's task for one visit: change set, bases, summary, and the re-derivation and repair sections when they apply. */
 export declare function deriverTask(change: string, changeSetLines: string[], bases: Record<string, string>, summary: string, repair: string | undefined, feedback?: string): string;
 /**
- * Writes the OpenSpec change for a diff that already exists (Flow mode): the
+ * Writes the OpenSpec change for a diff that already exists (Intent mode, formerly Flow): the
  * `deriver` authors the artifacts, then Core measures coverage, completed tasks,
  * strict validation and the archive preflight itself. Coverage gaps never fail
  * the node; they reach the reviewer through derivation.json as issues.

package/dist/agent-runtime/engine/pieces/derive-change.js

@@ -130,7 +130,7 @@ function verificationProposals(structured) {
     return Array.isArray(structured?.verification) ? structured.verification.slice(0, VERIFICATION_PROPOSALS_LIMIT) : [];
 }
 /**
- * Writes the OpenSpec change for a diff that already exists (Flow mode): the
+ * Writes the OpenSpec change for a diff that already exists (Intent mode, formerly Flow): the
  * `deriver` authors the artifacts, then Core measures coverage, completed tasks,
  * strict validation and the archive preflight itself. Coverage gaps never fail
  * the node; they reach the reviewer through derivation.json as issues.

package/dist/agent-runtime/prompts.d.ts

@@ -5,7 +5,7 @@ import type { DeveloperRecord } from './graph/state.js';
 import { type ClarificationPolicy } from './graph/clarifications.js';
 import type { ProjectRulesContext } from './project-rules.js';
 /** Bump whenever the wording changes: the version is part of the frozen run identity. */
-export declare const ROLE_INSTRUCTIONS_VERSION = "17";
+export declare const ROLE_INSTRUCTIONS_VERSION = "18";
 export interface RoleFeedback {
     verification?: unknown;
     review?: unknown;

package/dist/agent-runtime/prompts.js

@@ -3,7 +3,7 @@ import { DEFAULT_REVIEW_POLICY, REVIEW_ASPECTS } from './graph/review-policy.js'
 import { REVIEW_BRIEF_RISK_LIMIT, REVIEW_BRIEF_SCHEMA, REVIEW_RISK_AREAS } from './graph/review-brief.js';
 import { CLARIFICATIONS_SCHEMA, CLARIFICATION_LIMIT, DEFAULT_CLARIFICATION_POLICY } from './graph/clarifications.js';
 /** Bump whenever the wording changes: the version is part of the frozen run identity. */
-export const ROLE_INSTRUCTIONS_VERSION = '17';
+export const ROLE_INSTRUCTIONS_VERSION = '18';
 const OUTPUT_TAIL = 6_000;
 /** One senior engineer, rendered once per role prompt (never repeated inside it): the identity the implement pipeline's roles share. */
 const ENGINEER = 'a T-shaped principal engineer with decades of delivery across web, mobile and backend systems: deep in software design and testing, broad across product, UX, data, security, infrastructure and operations; fluent in hexagonal (ports and adapters) architecture, SOLID, design patterns, Clean Code, The Pragmatic Programmer, refactoring, legacy-code seams and AI-assisted development. You work for the user, the operator and the next maintainer, and you treat AI-generated code, including your own, with the scepticism owed to any untrusted contribution.';
@@ -279,6 +279,8 @@ function reviewerSection(policy, criteria, definition, adopted = false) {
         '8. What tests rarely catch: swallowed or context-free errors, missing cancellation, timeouts or cleanup, races and partial failures, retries without idempotency, empty, huge, malformed or boundary inputs, time zones and Unicode, secrets or personal data in logs, non-additive migrations or persisted-format changes, a removed guard or branch without a stated reason (understand before approving its removal), and artifacts the change made stale: localized strings in every locale the repository ships, documentation, schemas, configuration examples. Missing stale-artifact updates inside the planned blast radius are issues; concerns outside it are findings.',
         '9. Spec claims: for each capability this change touches (its delta specs under the change, and `openspec/specs/<capability>/spec.md` when it exists), compare what the requirements and scenarios claim with what the code does. A claim the code contradicts is a divergence for the brief (`divergences`), with the requirement and the observed behaviour at `file:line`. It is an issue only when this change introduced the contradiction.',
         '',
+        'The Intent block a spec may carry (problem, outcome, hypothesis, success signals, open questions) is context, never a requirement: a hypothesis is validated with real users after the change ships, a success signal is measured then, and an open question is a decision the spec records. Never raise an issue because the change does not prove the hypothesis, does not measure a signal or leaves such a question open; mention it in `brief` at most. Issues name defects in the code, tests missing for an ADDED or MODIFIED requirement, or an artifact that contradicts the code. Approve when none remains.',
+        '',
         'Judge BEHAVIOUR against the acceptance criteria, never the shape of the code against the wording of the plan: module layout, file lists, class or function names, naming conventions and implementation techniques named in the ticket, the design or a "contract layer" are suggestions the developer may legitimately improve on. A working implementation that satisfies a criterion by other means is correct; asking to rename, move or rewrite it to match the plan\'s wording is NOT an issue. Only a criterion that is not met, a defect, a missing test or a regression is.',
         '',
         'Review THE CHANGE. The change set below lists every file this run changed relative to its base, measured by Core from git. Judge those changes and the behavior they affect; code the change did not touch is not an issue unless the change breaks it. Never ask for improvements to pre-existing code, other packages or workspaces, or configuration outside the change; asking to REVERT an edit this change introduced is always in scope. An environment problem (credentials, registry access, missing tools) is not a code issue: record it under findings, never as an issue for the fixer.',

package/dist/pipeline/pipeline-state.d.ts

@@ -281,6 +281,13 @@ declare function inspectReceipt(state: PipelineState, env?: NodeJS.ProcessEnv):
     reasons: string[];
     receipt?: VerificationReceipt;
 };
+/**
+ * The requirement a spec without acceptance criteria freezes: its description
+ * minus the intent block. A hypothesis is validated with users after the
+ * change ships and its success signals are measured then; freezing them would
+ * make the reviewer demand evidence no code can give.
+ */
+export declare function requirementFromDescription(description: string, title: string): string;
 /** The frozen requirements an acceptance report must certify, in scope order. */
 export declare function frozenAcceptanceCriteria(contextInput: unknown): Array<Pick<AcceptanceCriterion, 'specId' | 'criterionIndex' | 'requirement'>>;
 /** Validates a report against the frozen scope without recording it; throws the same errors `recordAcceptance` would. */

package/dist/pipeline/pipeline-state.js

@@ -604,8 +604,26 @@ function taskGate(state) {
 }
 /** Stable indices refer to the frozen scope, never to rewritten design text.
  * When no explicit AC list exists, the frozen description is the requirement. */
+/** Heading of the intent block a host prepends to a spec's description (Desktop
+ *  `renderIntentForAgents`): why and outcome, never a requirement to certify. */
+const INTENT_BLOCK_HEADING = /^## Intent \(/m;
+/**
+ * The requirement a spec without acceptance criteria freezes: its description
+ * minus the intent block. A hypothesis is validated with users after the
+ * change ships and its success signals are measured then; freezing them would
+ * make the reviewer demand evidence no code can give.
+ */
+export function requirementFromDescription(description, title) {
+    const start = description.search(INTENT_BLOCK_HEADING);
+    if (start === -1)
+        return description || title;
+    const rest = description.slice(start + 1);
+    const next = rest.search(/^## /m);
+    const stripped = (description.slice(0, start) + (next === -1 ? '' : rest.slice(next))).trim();
+    return stripped || title;
+}
 function frozenCriteria(context) {
-    return context.specs.flatMap(spec => (spec.acceptanceCriteria?.length ? spec.acceptanceCriteria : [spec.description || spec.title])
+    return context.specs.flatMap(spec => (spec.acceptanceCriteria?.length ? spec.acceptanceCriteria : [requirementFromDescription(spec.description, spec.title)])
         .map((requirement, criterionIndex) => ({ specId: String(spec.id), criterionIndex, requirement })));
 }
 /** The frozen requirements an acceptance report must certify, in scope order. */

package/integration-contract.json

@@ -1,5 +1,5 @@
 {
-  "schemaVersion": "5.9",
+  "schemaVersion": "5.10",
   "providers": {
     "claude": {
       "cli": {
@@ -415,7 +415,7 @@
     "specificationFormat": "Architect specs are OpenSpec delta specs authored through the official fast-forward skill (ADDED/MODIFIED/REMOVED/RENAMED requirements); existing requirements are preserved through delta semantics and merged into main specs by OpenSpec archive. Complete replacement specs are not fabricated.",
     "compatibility": "Additive to integration schema 4 and execution context schema 1. Legacy workflows and profile v1 remain supported. Hosts must check RUNTIME_API_VERSION, not infer runtime support from Core major version.",
     "documentation": "docs/agent-runtime.md",
-    "instructionsVersion": "17",
+    "instructionsVersion": "18",
     "workflowVersion": "7",
     "engines": [
       1,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "specrails-core",
-  "version": "6.7.0",
+  "version": "6.7.1",
   "description": "Agent workflow engine for specrails-desktop: provider-independent installer and programmatic agent runtime for Claude Code and Codex",
   "type": "module",
   "exports": {