agent-tempo 1.6.0 → 1.6.2

package/dist/utils/secrets.d.ts

@@ -0,0 +1,34 @@
+/**
+ * Shared secret-classification — the single source of truth for "does this config
+ * key / env-var name hold a credential?" Used by:
+ *   - `cli/config-command.ts` — masks secret VALUES in the config display (#684).
+ *   - `spawn.ts` — partitions terminal-launch env so secret VALUES go to a 0600
+ *     file instead of being inlined into the echoed command (#689).
+ *
+ * Lives in `utils/` (not `cli/`) so `spawn.ts` can import it without a layering
+ * violation (spawn must not depend on the CLI surface). Extracted from
+ * config-command.ts in #689 so the two consumers share ONE classifier and can't
+ * drift — a secret added to the pattern is masked AND kept off the command line
+ * everywhere at once.
+ */
+/**
+ * Config/env keys that hold a credential value and must never be displayed raw or
+ * inlined into a command. Extend this (or {@link SECRET_KEY_PATTERN}) when a new
+ * secret config field / env var is introduced — both consumers pick it up.
+ */
+export declare const SECRET_KEYS: Set<string>;
+/**
+ * Matches credential-bearing key/env names: `*_API_KEY` / `*ApiKey` / `*Token` /
+ * `*Secret` / `*Password`. NOT `*Path` fields (those are file LOCATIONS, not the
+ * secret material — e.g. `temporalTlsKeyPath` must stay visible); the `path$`
+ * guard in {@link isSecretKey} excludes them.
+ */
+export declare const SECRET_KEY_PATTERN: RegExp;
+/**
+ * True when a config key or environment-variable name holds a credential value
+ * that must be masked on display and kept out of an echoed command line.
+ *
+ * Keys on the NAME, not the value. `*Path` fields are file locations (not secret
+ * material) and are explicitly excluded so they stay visible/inline.
+ */
+export declare function isSecretKey(key: string): boolean;

package/dist/utils/secrets.js

@@ -0,0 +1,47 @@
+"use strict";
+/**
+ * Shared secret-classification — the single source of truth for "does this config
+ * key / env-var name hold a credential?" Used by:
+ *   - `cli/config-command.ts` — masks secret VALUES in the config display (#684).
+ *   - `spawn.ts` — partitions terminal-launch env so secret VALUES go to a 0600
+ *     file instead of being inlined into the echoed command (#689).
+ *
+ * Lives in `utils/` (not `cli/`) so `spawn.ts` can import it without a layering
+ * violation (spawn must not depend on the CLI surface). Extracted from
+ * config-command.ts in #689 so the two consumers share ONE classifier and can't
+ * drift — a secret added to the pattern is masked AND kept off the command line
+ * everywhere at once.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.SECRET_KEY_PATTERN = exports.SECRET_KEYS = void 0;
+exports.isSecretKey = isSecretKey;
+/**
+ * Config/env keys that hold a credential value and must never be displayed raw or
+ * inlined into a command. Extend this (or {@link SECRET_KEY_PATTERN}) when a new
+ * secret config field / env var is introduced — both consumers pick it up.
+ */
+exports.SECRET_KEYS = new Set([
+    'temporalApiKey',
+    'httpToken',
+    'readToken',
+    'adminToken',
+]);
+/**
+ * Matches credential-bearing key/env names: `*_API_KEY` / `*ApiKey` / `*Token` /
+ * `*Secret` / `*Password`. NOT `*Path` fields (those are file LOCATIONS, not the
+ * secret material — e.g. `temporalTlsKeyPath` must stay visible); the `path$`
+ * guard in {@link isSecretKey} excludes them.
+ */
+exports.SECRET_KEY_PATTERN = /(api[_-]?key|token|secret|password)/i;
+/**
+ * True when a config key or environment-variable name holds a credential value
+ * that must be masked on display and kept out of an echoed command line.
+ *
+ * Keys on the NAME, not the value. `*Path` fields are file locations (not secret
+ * material) and are explicitly excluded so they stay visible/inline.
+ */
+function isSecretKey(key) {
+    if (/path$/i.test(key))
+        return false;
+    return exports.SECRET_KEYS.has(key) || exports.SECRET_KEY_PATTERN.test(key);
+}

package/examples/agents/tempo-conductor.md

@@ -57,6 +57,18 @@ You are a combination of Product Manager, Task Decomposition Expert, and Context
 - **Wrap-up**: Collect final reports, synthesize results, `detach` players who may be needed again (or `destroy` those who are truly done), report completion.
 - **Autonomous work session**: Pre-flight (check ensemble state — skip if active work is in progress) → review backlog → close completed items → identify tasks your ensemble can handle autonomously (flag those needing human design input) → kick off, track to completion, summarize results.
 
+## Message Delivery Model
+
+Understanding how cues are delivered prevents the most common conductor anti-pattern — busy-waiting for replies.
+
+**Cues wake you; you don't need to poll.** After cueing a player and expecting a reply, end your turn. When the reply arrives, the runtime wakes you automatically at the next turn boundary. There is nothing to poll.
+
+**`listen` is a one-shot inbox drain, not a wait primitive.** `listen` reads whatever messages are already queued at call time — it cannot block or wait for future messages. A `sleep`+`listen` loop does not work as a wait: it burns tokens across every player in the ensemble without advancing any work. If you're waiting for a reply, end your turn.
+
+**Don't reply to ack/FYI cues.** If a player sends a status update or acknowledgment without asking a question or requesting action, do not respond. Responding starts a ping-pong — your reply wakes them, they acknowledge, you're awake again — that wastes turns on both sides for zero information transfer.
+
+**Cues queue, they don't interrupt.** A cue sent to you while you're processing arrives at your next turn boundary, not mid-turn. A burst from multiple players arrives together; process the batch in one turn rather than starting a separate turn for each.
+
 ## Worktree Coordination
 
 Use the `worktree` tool to give players isolated git checkouts when two or more engineers need to work in the same repo on different branches simultaneously. Each worktree is an independent checkout — players can build, test, and commit without interfering with each other.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-tempo",
-  "version": "1.6.0",
+  "version": "1.6.2",
   "description": "Many agents, one tempo. Durable coordination for multi-agent work via Temporal.",
   "keywords": [
     "mcp",