| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
feat(workbot): Your agent's brief, one check rhythm and check→message (#6966) * feat(features): declare workbotAgentBrief, off Signed-off-by: Benjamin Shafii <benjamin.shafii@gmail.com> * feat(automations): port Your agent's check and message prompts, one rhythm and Den's hard limits Behind workbotAgentBrief. Adds @openwork/automations/proactive-brief: the spec's step 1 (check) and step 2 (message) prompts as constants, the check rhythm anchored to the working day in the member's zone, request_check planning (capped, inside hours, idempotent), the two answers parsed at the boundary, and the delivery limits (hours, quiet hours, told-once with one update a day, sources read, the daily limit). Shared types gain the brief settings, the member's brief edits and carrying the earlier settings over. Signed-off-by: Benjamin Shafii <benjamin.shafii@gmail.com> * feat(den-api): Your agent's brief, rhythm and check→message pipeline Behind workbotAgentBrief (on top of workbotProactive). The worker picks the wake per member: off, today's wake runs unchanged (shared calendar look and notices moved to wake-shared.ts, no behavior change; the legacy prompts are pinned by hash). On, each check runs on the one rhythm: step 1 in the agent's own read-only session with the spec's check prompt and the brief, step 2 only for P0/P1 findings in a fresh tool-less session with the member's recent Workbot DM, retried once when malformed, then Den's hard limits and the same Workbot DM. - request_check(at, why): an MCP tool only the agent's own check token sees, capped per day, inside hours, idempotent, audited. - Settings: brief settings resolved (saved, else carried over from responsibilities, instructions and the old limit); members add brief lines and slow the rhythm from chat or the page, server-enforced, with undo. - Records and counters: no_findings / findings_held reasons, a 'requested' kind and one 'rhythm' counter row, all additive for /admin readers. - Token usage per step is logged (workbot_agent_step_usage). Signed-off-by: Benjamin Shafii <benjamin.shafii@gmail.com> * test(den-api): the brief's settings, member changes and request_check through the API Off: today's routes, the brief's fields refused. On: carried over from responsibilities and instructions until saved, members' brief lines and rhythm from chat and the page with server limits and undo, and request_check only for the agent's own check token. Signed-off-by: Benjamin Shafii <benjamin.shafii@gmail.com> * test(evals): replay recorded days through today's prompts and the brief's pipeline Twelve fictional recorded days (calendar, Gmail, Slack, GitHub, a bandwidth bill, an exposed key over two days, cap exhaustion, noise, 'I'll handle it after lunch'), each item visible from when it happened. Both pipelines run with the same model and read-only tools; scored deterministically (missed, unwanted, silence, lead and length, links, formatting) and by an LLM judge. pnpm --dir evals agent:brief-replay. Signed-off-by: Benjamin Shafii <benjamin.shafii@gmail.com> * feat(den-web): Your agent's brief in Manage › Workbot and My bot Behind workbotAgentBrief (the server sends brief settings only then). Manage › Workbot shows one rhythm (Check every 2 hours, 8 AM–7 PM, weekdays), messages per person per day, extra checks agents may ask for and What to tell people with Reset to default, in place of the four message types, the lead time and the instructions; health becomes one row. My bot shows the next checks with why, Your brief with where it came from and Undo, the organization's brief behind a disclosure, and how often it checks within the admin's limit. Signed-off-by: Benjamin Shafii <benjamin.shafii@gmail.com> * fix(agent-brief): ids as <source>:<id>, the check knows what reached the member, no same-day nagging Prompt changes from the replay evals (spec v0 → v1), each for a failure the runs showed: - step 1 writes ids as <source>:<id> with the source as the wake lists it and the tool's id, the same every time, and step 2 copies them: told-once was defeated by 'GitHub alert:41' vs 'github:acme/robot-api#41'; - step 1 counts a finding again only if it changed or is still open on a later day or past a handle-by time, judged against what was sent (Den now lists it in the check prompt), not what it reported: repeats every check, and held P1s getting lost; - step 2: 'Still unresolved' is for an earlier day; - request_check only when something could change by then, not to see whether they acted; - a risk the brief asks about is at least P1 the first time (the spec's own bandwidth example was rated P2 in 9 of 9 runs). Den: remembers what it sent for a day and a half (encrypted state); a message naming only sources it didn't read is recorded as unreadable, not already told. Brief textarea in the body font (DESIGN V1). Signed-off-by: Benjamin Shafii <benjamin.shafii@gmail.com> * fix(agent-brief): carry held findings to the next check; act-by, not event time Prompt and Den changes from the replay evals (v1 → v3): - Den hands the next check its last report (encrypted state), and step 1's report keeps every finding still to tell: a P1 the messenger held was dropped at the next check because that check only reads what's new; - 'Something missing (no agenda, no prep notes) isn't a finding by itself': first checks sent 'no agenda found' messages; - P1 'even if its date is weeks away' for something the brief asks about; - step 2: the moment a P1 matters is when they'd have to act, not when the event is. Evals: Slack search returns thread replies as their own messages, as Slack does; PR #812's required item is the release-blocker escalation, the review request alone is fine. Signed-off-by: Benjamin Shafii <benjamin.shafii@gmail.com> * docs(agent-brief): the feature doc with screenshots, eval results and every prompt change Manage › Workbot before and after, My bot with the brief and next checks, and four recorded days rendered as Workbot DMs (old prompts next to the new pipeline). The proof world is pinned to noon so the extra check always sorts before the next slot. Your agent's and My bot's docs point at the brief. Signed-off-by: Benjamin Shafii <benjamin.shafii@gmail.com> --------- Signed-off-by: Benjamin Shafii <benjamin.shafii@gmail.com> | 19 小时前 | |
chore(deps): patch zod, Sentry, DOMPurify and toml advisories (#6430) * chore(deps): patch zod, Sentry, DOMPurify, toml, ip-address and Vitest advisories Bumps zod to 4.6.6 everywhere (including the two MCP servers still on zod 3), @sentry/nextjs to 10.75.2, dompurify to 3.4.17, and pins toml 5.0.1 and ip-address 10.7.4 through overrides. Evals move to vitest 4.1.12. The .opencode npm lockfile picks up the patched zod and toml. Next.js is handled separately in #6416. * chore(den): regenerate API contract for zod 4.6 zod 4.6 emits nullable unions as type arrays and requires seconds in ISO date-time patterns (RFC 3339). | 12 天前 | |
perf(build): reuse shared types and remove redundant build work (#5469) * perf(build): reuse shared types and remove redundant build work Den production builds rechecked workspace implementations after building their dependencies. Emit checked declarations per file, select them through an opt-in type export condition, and reject missing declarations before compiling the API. Keep source resolution for development and preserve the existing compiler heap override. Use the same declaration settings across eighteen shared packages. Build dependency graphs in order without the database rebuilding utilities, trim unconsumed JavaScript outputs from the shared types package, and include the build configuration in pruned Docker contexts. Focused validation: Den API, Gateway and Den Gateway builds; the Den API production compile reads no shared implementation files; shared package typechecks. Signed-off-by: Jalil <reachjalil@gmail.com> * fix(build): cover exports added since the declaration boundary The Den API production build now requires every workspace export it reads to publish a declaration through the openwork-build condition. Exports added on dev in the meantime did not: three den-db entry points and the new managed-deployments package, which had no declaration build at all. Give them the same declaration setup as the other shared packages. The telemetry analytics builders also published inferred drizzle types that name drizzle-orm, which the telemetry package does not depend on, so the API compile saw `any`. Declare their row types instead; the builders and their queries are unchanged. Signed-off-by: Jalil <reachjalil@gmail.com> --------- Signed-off-by: Jalil <reachjalil@gmail.com> | 22 天前 | |
feat(features): roll out features by deployment and organization, with a kill switch (#5702) * feat(den): declare features once in a registry stored per organization Adds packages/types/src/den/features.ts as the single place a feature is declared. Each entry decides, separately for OpenWork Cloud and self-hosted, whether the feature exists (unavailable / off / on) or is controlled per organization by platform admins, with a default. - Storage moves from organization.metadata.capabilities to a new organization_feature table (migration 0129 copies existing overrides and the old Connect aliases). Better Auth never writes it, so creating an organization can no longer turn features on; metadata.capabilities is stripped at creation and no longer sent to members. Writes are mirrored into metadata for one release so a rollback keeps working. - den-api reads features only through features.ts (getOrganizationFeatures, organizationFeatureEnabled, requireFeature). The three hand-written capability helper modules are deleted. - DEN_DEPLOYMENT (default self_hosted) and DEN_FEATURE_* locks, rendered from a generated Helm config.features block with a values schema. A lock outranks a stored override. - /admin schemas and the Den admin panel are generated from the registry, with Default / override / locked states and "Use default". - GET /v1/org adds features; capabilities stays frozen for published clients. - pnpm features:sync / features:check plus a CI job keep the chart in step and reject new DEN_*_ENABLED switches or metadata.capabilities reads. - add-a-feature skill and an AGENTS.md line: flag first, before feature code. No behavior change: every existing feature keeps its current default and stays platform-controlled on both deployments. * refactor(features): move the registry into its own @openwork/features package The registry and resolver were runtime logic living in @openwork/types. They now live in packages/features: - src/registry.ts: the one file you edit to declare a feature - src/resolve.ts: precedence rules, env parsing, key schema (pure, no I/O) - src/resolve.test.ts: node:test coverage of the precedence rules, env parsing, key schema and DEN_FEATURE_* names, run in features-check CI Files import each other through package self-references, so the TypeScript source runs as-is under Node (verified in the node:22 production image) and typechecks in every consumer without a build step. Also adds the package to the den, gateway and den-web Docker images and to the den-contract CI path filters, and pins azure/setup-helm to a commit SHA (Warden finding). * ci(features): check that Dockerfiles copy every workspace package they need The den, gateway, den-web and den-gateway images copy workspace packages one by one for layer caching, and only publish-ee-images builds them, so a missed COPY line surfaced at release time. scripts/check-docker-workspace-packages.mjs reads the manifests and Dockerfiles (about 10 ms) and fails when a copied package.json depends on a workspace package whose package.json is not copied (pnpm install fails) or a copied source folder imports one at runtime that is not copied. It runs inside pnpm features:check, and the workflow now also triggers on Dockerfile, workspace and package.json changes. * ci(features): name the exact setup-helm version in its pin comment * feat(features): roll features out by deployment, percentage, organization and kill switch A feature is no longer "per organization". Each registry entry declares only what is fixed in code: its subject (organization, or person so signed-out desktop users are included), the deployments it exists on, and its starting percentage. Everything else is runtime state, resolved by one function in @openwork/features, in this order: not part of this deployment, kill switch, operator lock (DEN_FEATURE_*), organization override, percentage of the subject (stable FNV-1a bucket; raising it only adds subjects). - feature_rollout table (migration 0129 now creates it alongside organization_feature) holds percentage and kill switch per feature. - /admin › Features page and GET/PUT /v1/admin/features change them without a deploy; organization rows show why a feature is on or off. - Admin MCP tools den_list_features and den_set_feature_rollout. - Public GET /v1/features/rollouts for clients that resolve person features themselves, including signed-out desktops. - /v1/org resolves person features for the signed-in member. - The nine existing features keep today's behaviour: organization subject, starting at 100% (install links, Connect) or 0% (the rest). - Skill, AGENTS.md, Helm comments and README describe the one model; features:check asks for a decision on rollouts older than six months unless marked permanent. * refactor(features): drop percentage rollouts; on or off for everyone, per organization, or killed Removes percentage rollouts and the organization/person subject they needed. A feature is now rolled out by deployment (fixed in code), on or off for everyone (/admin, starting from the registry default), per-organization overrides, operator locks, and the kill switch. feature_rollout stores enabled and killed; GET /v1/features gives people without an organization the deployment-wide answer. | 29 天前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 19 小时前 | ||
| 12 天前 | ||
| 22 天前 | ||
| 29 天前 |