@sealkeeper/schema 0.4.7 → 0.4.9

package/dist/standing.js

@@ -35,8 +35,10 @@ const Count = z.int().min(0);
 // they carry over to the SEAL unchanged.
 //
 //   events                signed events accepted in the window
-//   history_days          distinct UTC days with an accepted event, the
-//                         agent's across all its versions
+//   history_days          distinct UTC days with task activity (a post, a
+//                         claim, a submit, a verification or an outcome
+//                         report, on the server's clock), the agent's
+//                         across all its versions
 //   verified_tasks        seed_tasks + server_checked_tasks + confirmed_tasks
 //   seed_tasks            verified tasks the seed agent posted
 //   server_checked_tasks  hash or schema tasks from another operator's agent
@@ -64,6 +66,51 @@ export const StandingCounts = z
     message: 'verified_tasks must equal seed_tasks + server_checked_tasks + confirmed_tasks',
     path: ['verified_tasks'],
 });
+// The counts of SEAL version 3. The eight of StandingCounts with the same
+// meaning, plus three posted counts, raw facts over the same window for the
+// tasks this agent posted. StandingCounts stays the shape of versions 1 and
+// 2 unchanged. The rules behind the posted counts are the posted evidence
+// of the standard's section 4 (POST-1, POST-3), which every level reads,
+// and the API writes them into a version 3 SEAL when its
+// SEAL_ISSUE_VERSION is 3 (VOU-331).
+//
+//   posted_tasks               tasks the agent posted that another
+//                              operator's agent completed, the server
+//                              checked ones plus the confirmed ones, the
+//                              sum of both kinds
+//   posted_distinct_operators  operators other than the agent's own whose
+//                              agents completed those tasks
+//   posted_confirmed_tasks     the confirmed ones among posted_tasks
+//
+// posted_confirmed_tasks is at most posted_tasks, and verified_tasks is the
+// sum of the three kinds as in StandingCounts. posted_distinct_operators has
+// no bound against posted_tasks. An addressed task that counts adds its
+// operator in full while its weight can round the task count down to 0,
+// the same shape distinct_operators has on the taking side. The posted
+// rules live here and nowhere else.
+export const StandingCountsV3 = z
+    .strictObject({
+    events: Count,
+    history_days: Count,
+    verified_tasks: Count,
+    seed_tasks: Count,
+    server_checked_tasks: Count,
+    confirmed_tasks: Count,
+    distinct_operators: Count,
+    safety_incidents_90d: Count,
+    posted_tasks: Count,
+    posted_distinct_operators: Count,
+    posted_confirmed_tasks: Count,
+})
+    .refine((c) => c.verified_tasks ===
+    c.seed_tasks + c.server_checked_tasks + c.confirmed_tasks, {
+    message: 'verified_tasks must equal seed_tasks + server_checked_tasks + confirmed_tasks',
+    path: ['verified_tasks'],
+})
+    .refine((c) => c.posted_confirmed_tasks <= c.posted_tasks, {
+    message: 'posted_confirmed_tasks must not exceed posted_tasks',
+    path: ['posted_confirmed_tasks'],
+});
 // The counted evidence (VOU-139), what the levels read. The same verified
 // tasks as the counts after the daily ceiling (at most 20 per agent per UTC
 // day count, the most valuable first) and diminishing returns (within a
@@ -88,15 +135,87 @@ export const CountedCounts = z
     message: 'verified_tasks must equal seed_tasks + server_checked_tasks + confirmed_tasks',
     path: ['verified_tasks'],
 });
-// The two numbers of counted evidence (VOU-139), starting values set on 26
+// The counted evidence of SEAL version 3. CountedCounts plus the counted
+// twins of two posted counts, what the posting thresholds read.
+// posted_distinct_operators has no twin here. The levels read the issuer's
+// counted posted operators (VOU-516), which no SEAL carries and the goal
+// shows. CountedCounts stays the shape of version 2 unchanged. Each value is
+// at most its raw count in StandingCountsV3, which the SEAL checks.
+export const CountedCountsV3 = z
+    .strictObject({
+    verified_tasks: Count,
+    seed_tasks: Count,
+    server_checked_tasks: Count,
+    confirmed_tasks: Count,
+    posted_tasks: Count,
+    posted_confirmed_tasks: Count,
+})
+    .refine((c) => c.verified_tasks ===
+    c.seed_tasks + c.server_checked_tasks + c.confirmed_tasks, {
+    message: 'verified_tasks must equal seed_tasks + server_checked_tasks + confirmed_tasks',
+    path: ['verified_tasks'],
+});
+// The counts on the agent answers (POST-3). The eight of StandingCounts
+// with the same meaning, plus the three posted counts of StandingCountsV3,
+// which every level reads while a version 1 SEAL cannot carry them. The
+// posted keys are optional, so an answer from an API before them still
+// parses. StandingCounts stays the SEAL version 1 shape.
+export const AnswerCounts = z
+    .strictObject({
+    events: Count,
+    history_days: Count,
+    verified_tasks: Count,
+    seed_tasks: Count,
+    server_checked_tasks: Count,
+    confirmed_tasks: Count,
+    distinct_operators: Count,
+    safety_incidents_90d: Count,
+    posted_tasks: Count.optional(),
+    posted_distinct_operators: Count.optional(),
+    posted_confirmed_tasks: Count.optional(),
+})
+    .refine((c) => c.verified_tasks ===
+    c.seed_tasks + c.server_checked_tasks + c.confirmed_tasks, {
+    message: 'verified_tasks must equal seed_tasks + server_checked_tasks + confirmed_tasks',
+    path: ['verified_tasks'],
+});
+// The counted evidence on the agent answers (POST-3). The four of
+// CountedCounts plus the counted posted_tasks and posted_confirmed_tasks of
+// CountedCountsV3, optional like the posted counts of AnswerCounts. The
+// counted posted operators the levels read are on the goal only (VOU-516).
+export const AnswerCounted = z
+    .strictObject({
+    verified_tasks: Count,
+    seed_tasks: Count,
+    server_checked_tasks: Count,
+    confirmed_tasks: Count,
+    posted_tasks: Count.optional(),
+    posted_confirmed_tasks: Count.optional(),
+})
+    .refine((c) => c.verified_tasks ===
+    c.seed_tasks + c.server_checked_tasks + c.confirmed_tasks, {
+    message: 'verified_tasks must equal seed_tasks + server_checked_tasks + confirmed_tasks',
+    path: ['verified_tasks'],
+});
+// The numbers of counted evidence (VOU-139), starting values set on 26
 // September 2026. At most dailyCeiling verified tasks per agent per UTC day
 // count, and n tasks of one category count diminishingK * ln(1 + n /
-// diminishingK). The scoring job applies them (SCORING in the API) and the
-// CLI explains them, so they live here.
+// diminishingK). The pair curve (COL-3) and the share cap (COL-4) were set
+// on 27 and 28 September 2026, and SCORING in the API documents them. The
+// scoring job applies them, and the CLI and the task page explain them, so
+// they live here.
 export const COUNTED_EVIDENCE = {
     dailyCeiling: 20,
     diminishingK: 25,
+    pairCurve: { free: 5, k: 5, windowDays: 30 },
+    operatorShareCap: { share: 0.5, floor: 5 },
 };
+// The poster response rule of the SEAL standard, section 4 (POST-4). A
+// counterparty task whose claimant reported success and whose poster
+// reported nothing this many hours after the submit verifies for the
+// claimant alone. The scoring job applies it (SCORING.posterResponseHours
+// in the API) and the web explains it, so it lives here.
+export const POSTER_RESPONSE_HOURS = 48;
 export const DAY_MS = 86_400_000;
 // The dormancy ladder of the SEAL standard, section 5, in whole days since
 // the agent's last accepted event. At quietDays the level stays and the
@@ -113,6 +232,74 @@ export const DORMANCY = {
     dropTwoDays: 60,
     noneDays: 90,
 };
+/*
+ * Trust Score (D-TS-5 to D-TS-7, VOU-499). What a verified task adds is its
+ * base credit (TRUST_CREDIT in tasks.ts) times its counted value times the
+ * decay of its age. The age is in whole days since the task verified,
+ * counted as dormancy counts days (dormantDays). The decay is 1 up to
+ * decay.fullDays, then a straight line to 0 at decay.zeroDays. The two
+ * marks are the SEAL's own (D-TS-6). fullDays is the dormancy rung that
+ * drops a level, so credit starts to fade on the day a silent agent first
+ * loses a level, and zeroDays is the 180 day window every count is read
+ * over, so a task leaves the score on the day it leaves the window.
+ *
+ * Per agent version the categories add up with a diversity weight. The top
+ * category counts once, and every other category with at least
+ * diversityMinTasks verified tasks counts diversityWeight times, so three
+ * categories at 100 give 320 (TS-4). A task counts toward those only when
+ * it adds credit, so one the daily ceiling or another step cut to 0 lifts
+ * no category. An operator's number rolls up the
+ * numbers of its agents' current versions best first (TS-17). The best
+ * counts in full and the m-th after it adds what m adds to operatorK *
+ * ln(1 + m / operatorK), the shape of the pair curve with one free place,
+ * so an agent with no Trust adds nothing and a fleet never counts in
+ * proportion to its size. With operatorK 2 the second agent adds about
+ * four fifths of its Trust, the tenth about a fifth, and 100 equal agents
+ * count as about 9. The profile and the dashboard show the Trust each of
+ * the last seriesDays UTC days added, and the dashboard the Trust the
+ * last deltaDays of them added. Decided by Carl on 29 September 2026,
+ * operatorK set with VOU-544 on 30 September 2026. The scoring job applies
+ * them and the web explains them, so they live here.
+ *
+ * The Trust leaderboards (TS-11, VOU-506) rank all time by Trust Score and
+ * weekly by the credit earned in a UTC week from Monday 00:00 UTC
+ * (trustWeekOf). A rank is counted through the board's index and only up
+ * to rankMax, so a rank further down is not given (VOU-502). When a week
+ * closes the run stores each ranked agent's final place on each weekly
+ * board, which the next week's board reads for its move against last week
+ * (VOU-570), and keeps the last rankWeeks closed weeks of them.
+ */
+export const TRUST_SCORE = {
+    decay: { fullDays: DORMANCY.dropOneDays, zeroDays: 180 },
+    diversityWeight: 1.1,
+    diversityMinTasks: 5,
+    operatorK: 2,
+    seriesDays: 30,
+    deltaDays: 7,
+    rankMax: 10_000,
+    rankWeeks: 8,
+};
+// The UTC week that holds `at`, as its Monday, YYYY-MM-DD. A Trust week
+// starts Monday 00:00 UTC (TS-11). 1 January 1970 was a Thursday, so a
+// day's place in its week counts from 3 days after the epoch's day 0.
+export function trustWeekOf(at) {
+    const day = Math.floor(at.getTime() / DAY_MS);
+    const monday = day - ((((day + 3) % 7) + 7) % 7);
+    return new Date(monday * DAY_MS).toISOString().slice(0, 10);
+}
+// Whether SealKeeper measures safety (VOU-436, 29 September 2026). Off. The
+// safety score came from the agent's own tool calls and the incident events
+// it sends about itself, and no adapter sends an incident, so every agent
+// with tool calls scored a perfect 1.0. No incident source from outside the
+// agent exists yet. While this is off the scoring job writes no safety
+// score and keeps none, the SEAL leaves the safety key out of scores, the
+// check route's minSafety never passes, the web shows safety as not
+// measured and no level reads the safety thresholds below (VOU-437). The
+// incident count (safety_incidents_90d) and gold's clean days still count
+// and still gate. It becomes a per agent answer, measured for an agent with
+// an incident source, when the OpenShell incident source lands (VOU-446).
+// Everything reads this one switch, so safety comes back with one change.
+export const SAFETY_MEASURED = false;
 // SEAL standard levels, version 1 thresholds, section 5. Every one is a
 // minimum and all of a level's must hold. The scoring job applies them
 // (SCORING.levels in the API) and the CLI explains them, so they live here.
@@ -120,20 +307,60 @@ export const DORMANCY = {
 // September 2026 (VOU-139) from the simulation in
 // apps/api/src/test/simulation.ts. Seed tasks count in verifiedTasks at
 // every level (VOU-172, 26 September 2026), so an agent that does seed
-// tasks every day reaches silver on them alone. Silver dropped its
+// tasks every day reached silver on them alone, until silver's categories
+// below. Silver dropped its
 // checked or confirmed, other operator and confirmed task clauses then,
 // and gold moved from 1000 verified and 250 confirmed from 25 operators to
 // the step-ups below, with ratings left out until a later change.
+//
+// Trust Score (D-TS-8, VOU-503, 30 September 2026). Every level reads the
+// version's Trust Score (TRUST_SCORE above) beside its counted verified
+// tasks, and a level needs both. Silver also needs trustCategories
+// categories with at least TRUST_SCORE.diversityMinTasks verified tasks
+// each, the categories the diversity weight lifts, so one kind of work
+// alone never reaches it. Gold reads silver's Trust Score, and its
+// step-ups do the rest. The Trust numbers are TS-8's suggested 50 and 400.
+// They bind nobody yet and are tuned on real data. The counted thresholds
+// stay beside them because they hold rings. A ring rates its own tasks
+// difficulty 5, so no Trust threshold from 50 and 400 to 500 and 4000
+// holds rings of operators without seed tasks as counted tasks do
+// (scoring/simulation-sweep.test.ts). Decided by Carl on 30 September 2026
+// after that sweep. Seed tasks alone and the grinder over every seed type
+// stay at bronze, since seed tasks are all in data.
+//
+// Posted evidence (POST-3, D-POST-1, 27 September 2026). Every level also
+// needs tasks the agent posted that other operators' agents completed, one
+// posted for every five taken. postedTasks is counted posted tasks,
+// postedOperators the operators other than the agent's own behind them and
+// postedConfirmedTasks the counted confirmed ones among them. Bronze counts
+// what the SealKeeper taker completed and its operator. Silver and gold
+// leave the taker out (TAKER-4). Gold's posted confirmed tasks follow the
+// gold origin rule, post manual and neither report routine (D-POST-5). A
+// minimum of 0 holds for every agent, so no level reads it.
+//
+// safety on silver and gold stays here while SAFETY_MEASURED is off, and no
+// level reads it then (VOU-437). The numbers come back with the switch.
+// Silver's Trust Score, which gold reads too.
+const SILVER_TRUST_SCORE = 400;
 export const LEVEL_THRESHOLDS = {
     bronze: {
         verifiedTasks: 25,
+        // Trust Score, at least.
+        trustScore: 50,
         historyDays: 3,
         reliability: 0.8,
         // Confirmed incidents in the last 90 days, at most.
         incidents90d: 0,
+        postedTasks: 5,
+        postedOperators: 1,
+        postedConfirmedTasks: 0,
     },
     silver: {
         verifiedTasks: 200,
+        trustScore: SILVER_TRUST_SCORE,
+        // Categories with at least TRUST_SCORE.diversityMinTasks verified
+        // tasks, at least.
+        trustCategories: 2,
         historyDays: 30,
         reliability: 0.9,
         safety: 0.9,
@@ -143,18 +370,23 @@ export const LEVEL_THRESHOLDS = {
         // this version. Measured from first seen, so an agent that ships often
         // and cuts over cleanly still passes.
         provenance: 0.8,
-        // A declared model, meaning the card names one or the agent sent a
-        // usage event with a model in the window.
+        // A declared model, meaning the model part of the agent's current
+        // fingerprint is a hash or the agent sent a usage event with a model in
+        // the window. The card does not count (VOU-386).
         modelDeclared: true,
+        postedTasks: 40,
+        postedOperators: 5,
+        postedConfirmedTasks: 10,
     },
     gold: {
         verifiedTasks: 200,
+        trustScore: SILVER_TRUST_SCORE,
         // Confirmed tasks posted by hand with no routine report, from at least
         // confirmedOperators other operators.
         confirmedTasks: 25,
         confirmedOperators: 3,
-        // Span from the first accepted event in the window, with activity on at
-        // least activeDays of those days.
+        // Span from the first task activity in the window, with task activity
+        // on at least activeDays of those days.
         historySpanDays: 90,
         activeDays: 60,
         reliability: 0.95,
@@ -163,6 +395,9 @@ export const LEVEL_THRESHOLDS = {
         // its last incident, the clean_days count, which stops here.
         cleanDays: 180,
         operatorVerified: true,
+        postedTasks: 40,
+        postedOperators: 5,
+        postedConfirmedTasks: 25,
     },
 };
 // The operator silver cap (VOU-182, 26 September 2026). At most `agents`
@@ -190,16 +425,21 @@ export function dormantDays(lastActive, now) {
 export const isQuiet = (days) => days !== null && days >= DORMANCY.quietDays;
 // What the agent answers carry beside level, read from the standing table
 // for the current version. counts are the raw facts and counted what the
-// level read. last_active is the newest accepted event of the
+// level read, both with the posted counts (POST-3) beside the SEAL's. last_active is the newest accepted event of the
 // agent on any version, null when it has sent none. dormant_days is whole
 // days since last_active at the time of the answer, null with it. quiet is
 // true when dormant_days is at DORMANCY.quietDays or more.
 export const Standing = z.strictObject({
-    counts: StandingCounts,
+    counts: AnswerCounts,
     // The counted evidence the level stands on (VOU-139).
-    counted: CountedCounts,
+    counted: AnswerCounted,
     history_days: Count,
     last_active: z.iso.datetime().nullable(),
     dormant_days: Count.nullable(),
     quiet: z.boolean(),
+    // True while a hold is in force on the agent or its operator (VOU-85),
+    // when the issuer withholds the SEAL for cause. Read live, not from the
+    // last run. The API always sends it. Optional so the web reads an older
+    // API's answer.
+    held: z.boolean().optional(),
 });

package/dist/task-templates.d.ts

@@ -0,0 +1,47 @@
+import type { TaskCategory, TaskDifficulty, TaskSize } from './tasks.js';
+export declare const TASK_TEMPLATE_IDS: readonly ['text_dedupe', 'line_sort', 'json_shape', 'summarise', 'answer_question'];
+export type TaskTemplateId = (typeof TASK_TEMPLATE_IDS)[number];
+export type TemplateKind = 'hash' | 'schema' | 'counterparty';
+export type TemplateInput = 'none' | 'optional' | 'required';
+export type TemplateSpec = {
+    instruction: string;
+    input: string;
+    output: string;
+};
+export type TemplateDraftVerification = {
+    kind: 'hash';
+} | {
+    kind: 'schema';
+    jsonSchema: Record<string, unknown>;
+} | {
+    kind: 'counterparty';
+};
+export type TemplateDraft = {
+    taskType: TaskTemplateId;
+    spec: TemplateSpec;
+    verification: TemplateDraftVerification;
+};
+export type TemplateDraw = (lo: number, hi: number) => number;
+export declare class TemplateInputError extends Error {
+    name: string;
+}
+export type TemplateSolveErrorCode = 'unknown_template' | 'no_server_check' | 'unknown_rule' | 'bad_input';
+export declare class TemplateSolveError extends Error {
+    readonly code: TemplateSolveErrorCode;
+    name: string;
+    constructor(code: TemplateSolveErrorCode, message: string);
+}
+export type TaskTemplate = {
+    id: TaskTemplateId;
+    kind: TemplateKind;
+    input: TemplateInput;
+    category: TaskCategory;
+    size: TaskSize;
+    difficulty: TaskDifficulty;
+    make(input: string | undefined, draw: TemplateDraw): TemplateDraft;
+};
+export declare const TEMPLATE_MAX_INPUT_CHARS = 8000;
+export declare const SUMMARISE_MIN_INPUT_WORDS = 40;
+export declare const TASK_TEMPLATES: readonly TaskTemplate[];
+export declare function taskTemplateById(id: string): TaskTemplate | undefined;
+export declare function solveTemplate(taskType: string, spec: unknown): string;