pi-harness-runtime 1.1.391 → 1.1.392

package/AGENTS.md

@@ -494,27 +494,45 @@ bun run build && bun run start   # Server deployment
 ### 14. Workspace Environment Auto-Detection
 
 **At session start, the harness auto-detects:**
-- `.env` file presence → Dev environment evidence
+- `.env` / `.env.*` file variables → Dev environment evidence
 - `package.json` `dev` script → Hot reload capability
-- `NODE_ENV` value → development/production/test
+- The environment variable, in this order: the `NODE_ENV` of the process env
+  (it decides, also when it names no known mode), then the dotenv files of the
+  workspace: `NODE_ENV`, an environment shaped key whose value names a known
+  mode (`*_ENV`, `*_ENVIRONMENT`, `*_MODE`, `*_STAGE`, e.g. `AMOS_ENV`), then
+  any other environment shaped key - and only then an environment shaped key
+  of the process env → development/production/test
 - System RAM → Low RAM warning (<16GB total or <4GB available)
 - Running processes → dev/build server status
 
+The dotenv files are read from the WORKSPACE (not from the current working
+directory), the template files (`.env.example`, `.env.sample`,
+`.env.template`, ...) are ignored and a file bigger than 256 kB is not read.
+A value that is not provably harmless is masked (`<set>`): only the
+`NODE_ENV` of the process env and a value that IS the name of the mode are
+shown. A key that only looks like a branch (`BRANCH=production`) never
+decides the mode.
+
 **This info is shown in UI and delivered to agent context:**
 ```
-Workspace: ~/pi-harness-runtime | OS: Linux | mode: DEVELOPMENT | dev server: running | dev script: available | build script: available | RAM: 10/16
+Workspace: ~/pi-harness-runtime | OS: Linux | mode: DEVELOPMENT (from AMOS_ENV in .env) | dev server: running | dev script: available | build script: available | RAM: 10/16
 ```
 
 The mode words are exactly what the detector emits: `DEVELOPMENT`, `PRODUCTION`,
-`TEST` or `UNKNOWN` (with its reason, e.g. `UNKNOWN (no explicit NODE_ENV)`).
+`TEST` or `UNKNOWN` (with its reason, e.g.
+`UNKNOWN (no NODE_ENV or environment variable found)` or
+`UNKNOWN (AMOS_ENV in .env names no known mode)`). A known mode also
+names its source: `DEVELOPMENT (from AMOS_ENV in .env)`.
 A dev/build script is a CAPABILITY, not a state: `dev script: available` means
 the script exists, not that a server runs. The server state is separate and
 never claims more than it knows: `running`, `not detected` (a check ran and
 found nothing) or `not checked` (no check was possible, e.g. no `pgrep`).
 
 The OS is part of the line because it decides which command prints the
-working directory: `pwd` on Linux/macOS, `cd` or `echo %cd%` on Windows.
-The agent context names the command to use.
+working directory: `pwd` on Linux/macOS, `(pwd).Path` or `$pwd.Path` in
+PowerShell (the plain `pwd` there prints a "Path: " header), `cd` or
+`echo %cd%` in the Windows command prompt. The agent context names the
+command to use.
 
 **IMPORTANT Rules:**
 
@@ -528,8 +546,11 @@ The agent context names the command to use.
 
 **Decision flow:**
 ```
-Check process.env.NODE_ENV first
-Check .env file NODE_ENV second
+Check process.env.NODE_ENV first (it decides, also when it names no known mode)
+Check the .env and .env.* files of the workspace second
+  (NODE_ENV, then an environment shaped key whose value names a mode,
+   then any other environment shaped key)
+Only then an environment shaped key of the process env (e.g. AMOS_ENV)
 Presence of dev script = capability, not proof of mode
 UNKNOWN requires investigation, not auto-build
 Production detection ≠ deployment authorization

package/harness/telegram-auth.ts

@@ -90,6 +90,38 @@ export function getAllowedUserIds(): Set<number> {
 	return new Set();
 }
 
+/**
+ * Describe who may write into Pi through Telegram.
+ *
+ * The allow-list falls back to the chat id file, and a GROUP chat id is
+ * negative - it identifies a chat, not a person. A sender rule that only
+ * knows a group id lets nobody in, silently. The description makes that
+ * visible.
+ */
+export function describeInboundAccess(
+	allowedUserIds: Iterable<number>,
+	chatId?: string,
+): string {
+	const ids = [...allowedUserIds].filter((n) => Number.isFinite(n));
+	const users = ids.filter((n) => n > 0);
+	const groups = ids.filter((n) => n < 0);
+	if (users.length === 0) {
+		const known = groups.length > 0 ? ` (the allow-list holds the group chat id ${groups.join(", ")})` : "";
+		return `nobody may write in${known}`;
+	}
+	const chat = chatId ? ` in chat ${chatId}` : "";
+	return `user id(s) ${users.join(", ")} may write in${chat}`;
+}
+
+/**
+ * Decide whether a Telegram sender may write into Pi.
+ *
+ * The rule itself lives in the notification package
+ * (packages/notification/src/telegram-auth.ts) so that the adapter, this
+ * module and the remote webhook server all use ONE implementation.
+ */
+export { isAuthorizedTelegramSender } from "../packages/notification/dist/telegram-auth.js";
+
 /**
  * Check if a Telegram user ID is authorized
  */

package/harness/telegram-update.ts

@@ -0,0 +1,125 @@
+/**
+ * Map a relay "telegram_message" payload onto a Telegram update.
+ *
+ * The mapping lives in a pure module so that it can be tested without the
+ * harness: the relay carries the text, the adapter decides whether the
+ * sender is allowed to write in.
+ *
+ * Rules:
+ *  - the text is never put into an id field (ids are logged by the client)
+ *  - the real bot flag has to survive the transport, otherwise the adapter
+ *    could not refuse bot messages
+ *  - a payload without text produces no update
+ */
+
+export interface TelegramMessageUpdate {
+	message: {
+		message_id: number;
+		from: {
+			id: number;
+			is_bot: boolean;
+			first_name: string;
+			username?: string;
+		};
+		chat: { id: number };
+		text: string;
+	};
+}
+
+export interface TelegramMessagePayload {
+	userId: number;
+	username?: string;
+	messageId?: number;
+	chatId?: number;
+	text?: string;
+	isBot?: boolean;
+}
+
+export interface TelegramCallbackUpdate {
+	callback_query: {
+		id: string;
+		from: {
+			id: number;
+			is_bot: boolean;
+			first_name: string;
+			username?: string;
+		};
+		data: string;
+		message: {
+			chat: { id: number };
+			message_id: number;
+		};
+	};
+}
+
+/**
+ * Build the Telegram update for a relayed button callback.
+ *
+ * The real bot flag has to survive the transport: the adapter refuses
+ * messages and callbacks of a bot.
+ */
+export function buildTelegramCallbackUpdate(
+	payload: TelegramMessagePayload & {
+		action?: string;
+		targetId?: string;
+		callbackQueryId?: string;
+		id?: string;
+	},
+): TelegramCallbackUpdate | null {
+	const userId = Number(payload.userId);
+	if (!Number.isFinite(userId)) return null;
+	const chatId = Number(payload.chatId);
+	const effectiveChatId = Number.isFinite(chatId) ? chatId : userId;
+	return {
+		callback_query: {
+			id: payload.callbackQueryId || String(payload.id || ""),
+			from: {
+				id: userId,
+				is_bot: payload.isBot === true,
+				first_name: payload.username || "User",
+				username: payload.username,
+			},
+			data: `${payload.action || ""}:${payload.targetId || ""}`,
+			message: {
+				chat: { id: effectiveChatId },
+				message_id: Number(payload.messageId) || 0,
+			},
+		},
+	};
+}
+
+/**
+ * Build the Telegram update for a relayed text message.
+ *
+ * Returns null when the payload carries no text - there is nothing to
+ * forward and the adapter must not see an empty message.
+ */
+export function buildTelegramMessageUpdate(
+	payload: TelegramMessagePayload,
+): TelegramMessageUpdate | null {
+	const text = payload.text ?? "";
+	if (!text) return null;
+
+	const userId = Number(payload.userId);
+	if (!Number.isFinite(userId)) return null;
+
+	// A direct message has the chat id of the user; the remote always sends
+	// the real chat id, so the fallback is only for a DM.
+	const chatId = Number(payload.chatId);
+	const effectiveChatId = Number.isFinite(chatId) ? chatId : userId;
+
+	return {
+		message: {
+			message_id: Number(payload.messageId) || 0,
+			from: {
+				id: userId,
+				// The real flag: the adapter refuses bot messages.
+				is_bot: payload.isBot === true,
+				first_name: payload.username || "User",
+				username: payload.username,
+			},
+			chat: { id: effectiveChatId },
+			text,
+		},
+	};
+}

package/index.ts

@@ -28,6 +28,8 @@ import {
 	type KeyFileAuditResult,
 } from "./harness/key-file-audit.ts";
 import { renderDetailLines } from "./harness/startup-lines.ts";
+import { describeInboundAccess, getAllowedUserIds } from "./harness/telegram-auth.ts";
+import { buildTelegramCallbackUpdate, buildTelegramMessageUpdate } from "./harness/telegram-update.ts";
 import {
 	jevMissingKeyReport,
 	lineConfigurationReport,
@@ -1364,6 +1366,7 @@ async function initTelegram(pi: ExtensionAPI): Promise<void> {
 			return;
 		}
 
+		const allowedUserIds = [...getAllowedUserIds()];
 		const channels: Array<{
 			id: string;
 			type: string;
@@ -1374,10 +1377,27 @@ async function initTelegram(pi: ExtensionAPI): Promise<void> {
 				id: "telegram",
 				type: "telegram",
 				enabled: true,
-				config: { botToken, chatId },
+				config: { botToken, chatId, allowedUserIds },
 			},
 		];
 
+		// Who may write into Pi? A group chat id is not a user id: when the
+		// allow-list holds only a group id, the inbound path is closed - and
+		// that must be visible, not silent.
+		const inboundAccess = describeInboundAccess(allowedUserIds, chatId);
+		logStartup(`[pi-harness] Telegram inbound: ${inboundAccess}`);
+		if (inboundAccess.startsWith("nobody")) {
+			addHarnessMessage(
+				"Telegram",
+				"nobody may write in: the allow-list holds no user id",
+				"warn",
+				[
+					"Write your Telegram user id into ~/.pi-harness-runtime/keys/telegram-allowed-users.txt (a chat id of a group is not a user id).",
+					"Then reload Pi.",
+				],
+			);
+		}
+
 		// Add LINE channel if credentials exist
 		const lineChannelConfigured = Boolean(hasLineCredentials && lineAccessToken && lineUserId);
 		if (lineChannelConfigured) {
@@ -1587,7 +1607,9 @@ async function initTelegram(pi: ExtensionAPI): Promise<void> {
 				return;
 			}
 			
-			logToFile("[TelegramInbound]", `Forwarding message to Pi: "${text.slice(0, 50)}..."`);
+			// The user's own words stay out of the log files: only the length
+			// is recorded.
+			logToFile("[TelegramInbound]", `Forwarding message to Pi (${text.length} chars)`);
 			// Forward the message to Pi as a user message
 			await pi.sendUserMessage(text, { deliverAs: "steer" });
 		});
@@ -1644,7 +1666,32 @@ async function initTelegram(pi: ExtensionAPI): Promise<void> {
 			]);
 			return;
 		}
-		telegram?.startPolling();
+		// Polling and the remote webhook are mutually exclusive. Telegram
+		// rejects getUpdates while a webhook is active, and the rejected poll
+		// also terminates the getUpdates stream of every other poller of this
+		// bot, which delayed the inbound text messages by seconds.
+		if (telegram) {
+			// A 409 (a webhook or another poller owns this bot) stops the
+			// inbound path. The user must see it - a silent 409 looks like a
+			// working inbound path.
+			telegram.onPollStopped = (reason) => {
+				addHarnessMessage("Telegram", `inbound polling stopped: ${reason}`, "warn", [
+					"Telegram rejects getUpdates (409) while a webhook or another poller owns this bot.",
+					"Stop the other poller of this bot (or remove the remote webhook), then reload Pi.",
+				]);
+			};
+			if (!telegram.isWebhookConfigured()) {
+				telegram.startPolling();
+				// The poll may already have been rejected (a 409 fires the
+				// callback above); make the reason visible either way.
+				const stopReason = telegram.getPollStopReason();
+				if (stopReason) {
+					addHarnessMessage("Telegram", `inbound polling stopped: ${stopReason}`, "warn", [
+						"Stop the other poller of this bot (or remove the remote webhook), then reload Pi.",
+					]);
+				}
+			}
+		}
 		if (!telegram?.isGreetingVerified()) {
 			addHarnessMessage("Telegram", "Hi sent; tap Say Hi to verify inbound (tap Toggle Telegram to disable)", "wait");
 		}
@@ -1931,33 +1978,57 @@ async function initRelayStream(): Promise<void> {
 				logToFile("[RelayStream]", "Synchronized - receiving live events");
 			},
 			onCallback: async (callback: CallbackPayload) => {
-				logToFile("[RelayStream]", `Callback: ${callback.action} ${callback.targetId}`);
+				logToFile(
+					"[RelayStream]",
+					callback.type === "telegram_message"
+						? `Message from ${callback.username || callback.userId} (${(callback.text || "").length} chars)`
+						: `Callback: ${callback.action} ${callback.targetId}`,
+				);
 
 				// Forward Telegram callbacks to the adapter
 				if (callback.type === "telegram_callback" && _relayTelegramAdapter) {
-					// Convert relay callback to Telegram update format
-					const update = {
-						callback_query: {
-							id: callback.callbackQueryId || String(callback.id),
-							from: {
-								id: callback.userId,
-								is_bot: false,
-								first_name: callback.username || "User",
-								username: callback.username,
-							},
-							data: `${callback.action}:${callback.targetId}`,
-							message: {
-								chat: { id: callback.chatId || callback.userId },
-								message_id: callback.messageId || 0,
-							},
-						},
-					};
+					// The mapping is a pure function (harness/telegram-update.ts) so
+					// that it can be tested without the harness.
+					const update = buildTelegramCallbackUpdate({
+						id: callback.id,
+						action: callback.action,
+						targetId: callback.targetId,
+						callbackQueryId: callback.callbackQueryId,
+						userId: callback.userId,
+						username: callback.username,
+						messageId: callback.messageId,
+						chatId: callback.chatId,
+						isBot: callback.isBot,
+					});
+					if (update) {
+						try {
+							await _relayTelegramAdapter.handleWebhookUpdate(update);
+							logToFile("[RelayStream]", "Callback processed by Telegram adapter");
+						} catch (err) {
+							logToFile("[RelayStream]", `Adapter error: ${oneLineError(err)}`);
+						}
+					}
+				}
 
-					try {
-						await _relayTelegramAdapter.handleWebhookUpdate(update);
-						logToFile("[RelayStream]", "Callback processed by Telegram adapter");
-					} catch (err) {
-						logToFile("[RelayStream]", `Adapter error: ${err}`);
+				// Forward a Telegram TEXT message (the user typed it) to the adapter
+				if (callback.type === "telegram_message" && _relayTelegramAdapter) {
+					// The mapping is a pure function (harness/telegram-update.ts) so
+					// that it can be tested without the harness.
+					const update = buildTelegramMessageUpdate({
+						userId: callback.userId,
+						username: callback.username,
+						messageId: callback.messageId,
+						chatId: callback.chatId,
+						text: callback.text,
+						isBot: callback.isBot,
+					});
+					if (update) {
+						try {
+							await _relayTelegramAdapter.handleWebhookUpdate(update);
+							logToFile("[RelayStream]", "Message processed by Telegram adapter");
+						} catch (err) {
+							logToFile("[RelayStream]", `Adapter error: ${oneLineError(err)}`);
+						}
 					}
 				}
 			},
@@ -2708,8 +2779,10 @@ const HARNESS_LOG_FILE = "/tmp/pi-harness.log";
 /** Log a harness message to file (not stderr - bypasses Pi's cursor tracking) */
 function logToFile(...parts: string[]): void {
 	const msg = parts.join(" ");
+	// A timestamp makes the log usable for latency measurements.
+	const stamp = new Date().toISOString();
 	try {
-		appendFileSync(HARNESS_LOG_FILE, msg + "\n");
+		appendFileSync(HARNESS_LOG_FILE, `[${stamp}] ${msg}\n`);
 	} catch {
 		// Ignore file write errors
 	}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-harness-runtime",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "description": "[BETA] Codex-style /usage status + autonomous coding harness for pi. Not production ready — expect breaking changes.",
   "type": "module",
   "scripts": {

package/packages/a2a-adapter/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/a2a-adapter",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "type": "module",
   "description": "Google Agent-to-Agent (A2A) protocol adapter for pi-harness",
   "main": "dist/index.js",

package/packages/agent-policy/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/agent-policy",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "description": "Agent policy runtime for pi-harness - enforces mandatory rule delivery and mutation gating",
   "type": "module",
   "main": "./dist/index.js",

package/packages/architecture-generator/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi-harness/architecture-generator",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "description": "Generate ADR and Mermaid diagrams from project analysis",
   "type": "module",
   "main": "./dist/index.js",

package/packages/auth/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi-harness/auth",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "description": "pi-harness-runtime — auth",
   "type": "module",
   "main": "./dist/index.js",

package/packages/autonomous-refactor/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/autonomous-refactor",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "type": "module",
   "description": "Autonomous refactoring engine",
   "main": "dist/index.js",

package/packages/autonomous-runtime/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/autonomous-runtime",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "description": "Autonomous Operations Runtime — task inbox, lease management, and worker lifecycle (RFC-0101)",
   "type": "module",
   "main": "./dist/index.js",

package/packages/cache-strategy/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/cache-strategy",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "type": "module",
   "description": "Smart caching with TTL and invalidation strategies (RFC-0022)",
   "main": "dist/index.js",

package/packages/capability-registry/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi-harness/capability-registry",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "description": "Capability Registry for pi-harness-runtime — tracks model capabilities and enables capability-based routing",
   "type": "module",
   "main": "./dist/index.js",

package/packages/checkpoint/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/checkpoint",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "description": "Enhanced checkpoint system with incremental snapshots, diff-based storage, and recovery strategies",
   "type": "module",
   "main": "./dist/index.js",

package/packages/cli-plugin-sdk/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/cli-plugin-sdk",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "type": "module",
   "description": "CLI Plugin SDK for pi-harness — install, list, remove, update, invoke plugins",
   "main": "dist/index.js",

package/packages/clipboard/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/clipboard",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "type": "module",
   "main": "src/index.ts",
   "exports": {

package/packages/clipboard-plugin/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/clipboard-plugin",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "type": "module",
   "main": "src/index.ts",
   "exports": {

package/packages/code-generation/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/code-generation",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "description": "Code generation pipeline for pi-harness-runtime",
   "type": "module",
   "main": "./dist/index.js",

package/packages/code-review/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/code-review",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "description": "Automated code review engine for pi-harness-runtime",
   "type": "module",
   "main": "./dist/index.js",

package/packages/codex-adapter/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/codex-adapter",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "type": "module",
   "description": "OpenAI Codex provider adapter for pi-harness",
   "main": "dist/index.js",

package/packages/codex-watcher/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi-harness/codex-watcher",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "description": "Watches Codex CLI sessions and emits visible messages for PING-PONG monitoring",
   "type": "module",
   "main": "./dist/src/index.js",

package/packages/config-capture/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@moocoding/config-capture",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "description": "Auto-capture API-fetched configuration values to AGENTS.md",
   "type": "module",
   "main": "src/index.ts",

package/packages/connection-runtime/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi-harness/connection-runtime",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "type": "module",
   "description": "Connection management with jittered exponential backoff for pi-harness",
   "main": "./dist/index.js",

package/packages/context-compiler/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/context-compiler",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "description": "Bounded context selection engine for pi-harness-runtime",
   "type": "module",
   "main": "./dist/index.js",

package/packages/context-discovery/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/context-discovery",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "type": "module",
   "main": "src/index.ts",
   "exports": {

package/packages/context-manager/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi-harness/context-manager",
-  "version": "1.1.391",
+  "version": "1.1.392",
   "description": "Context Window Manager — prevents model context overflow via compaction and resume prompts (RFC-0010)",
   "type": "module",
   "main": "./dist/index.js",

package/packages/contracts/dist/workspace-dotenv.d.ts

@@ -0,0 +1,44 @@
+/**
+ * Reading the dotenv files of a workspace.
+ *
+ * This module owns the file system part of the environment detection: it
+ * finds the ".env" files of a workspace, reads them and skips what must not
+ * be read (templates, huge files, unreadable files).
+ *
+ * It is deliberately free of any other dependency (no node:sqlite) so it
+ * can be unit tested everywhere: the detection module itself needs
+ * node:sqlite, which not every runtime provides.
+ */
+/**
+ * The biggest dotenv file that is read. A ".env" file is a few kilobytes;
+ * anything bigger is not a configuration file (and reading it on every
+ * session start would be a waste).
+ */
+export declare const DOTENV_MAX_BYTES: number;
+/**
+ * True for a template file that only documents the variables
+ * (".env.example", ".env.sample", ".env.template", ...).
+ *
+ * A template is not the configuration of the workspace: it must never
+ * decide the mode. The marker is looked for in EVERY segment of the
+ * suffix, so ".env.example.local" is a template too.
+ */
+export declare function isTemplateDotenvName(name: string): boolean;
+/**
+ * The dotenv files of a workspace as FULL paths, in the order they are read.
+ *
+ * ".env" comes first, then the well known variants, then every other
+ * ".env.*" file. Template files are skipped.
+ */
+export declare function listDotenvFiles(workspacePath: string): string[];
+/**
+ * Read the dotenv files of a workspace.
+ *
+ * The files are read through the full paths of listDotenvFiles, so the
+ * workspace - not the current working directory - decides which files are
+ * read.
+ */
+export declare function readDotenvFiles(workspacePath: string): {
+    name: string;
+    content: string;
+}[];