@hassangameryt/freeflow 0.7.3 → 0.8.0

package/pi-extension/tests/settings/settings-tui.test.js

@@ -1,243 +0,0 @@
-import assert from "node:assert/strict";
-import test from "node:test";
-
-import { CURSOR_MARKER, visibleWidth } from "@earendil-works/pi-tui";
-
-import { PiSettingsComponent } from "../../dist/settings/settings-tui.js";
-
-const theme = {
-  fg(_color, text) {
-    return text;
-  },
-  bold(text) {
-    return text;
-  },
-};
-
-function deferred() {
-  let resolve;
-  let reject;
-  const promise = new Promise((resolvePromise, rejectPromise) => {
-    resolve = resolvePromise;
-    reject = rejectPromise;
-  });
-  return { promise, resolve, reject };
-}
-
-function createComponent(entries, options = {}) {
-  const notifications = [];
-  let closed = false;
-  const component = new PiSettingsComponent({
-    title: options.title ?? "Test Settings",
-    entries,
-    theme: options.theme ?? theme,
-    requestRender() {},
-    notify(message, level) {
-      notifications.push({ message, level });
-    },
-    done() {
-      closed = true;
-    },
-  });
-  return { component, notifications, isClosed: () => closed };
-}
-
-test("Pi settings publish values only after persistence and block concurrent edits", async () => {
-  let current = "disabled";
-  let commits = 0;
-  const write = deferred();
-  const entry = {
-    id: "feature.enabled",
-    label: "Feature",
-    description: "Enable the feature.",
-    currentValue: () => current,
-    inactive: () => false,
-    currentChoiceKey: () => (current === "enabled" ? "true" : "false"),
-    choices: [
-      { key: "true", value: true, label: "enabled" },
-      { key: "false", value: false, label: "disabled" },
-    ],
-    async commit() {
-      commits += 1;
-      await write.promise;
-      current = "enabled";
-      return { changed: true, reloadRequired: true };
-    },
-  };
-  const { component } = createComponent([entry]);
-
-  component.handleInput("\r");
-  component.handleInput("\u001b[A");
-  component.handleInput("\r");
-  component.handleInput("\r");
-
-  assert.equal(commits, 1);
-  assert.equal(current, "disabled");
-  write.resolve();
-  await component.waitForWrites();
-  assert.equal(current, "enabled");
-  assert.match(component.render(80).join("\n"), /Feature\s+enabled/);
-  assert.deepEqual(component.sessionResult(), { changed: true, configChanged: true, failed: false });
-});
-
-test("Pi settings retain the persisted value when a write fails", async () => {
-  const current = "disabled";
-  const entry = {
-    id: "feature.enabled",
-    label: "Feature",
-    description: "Enable the feature.",
-    currentValue: () => current,
-    inactive: () => false,
-    currentChoiceKey: () => "false",
-    choices: [
-      { key: "true", value: true, label: "enabled" },
-      { key: "false", value: false, label: "disabled" },
-    ],
-    async commit() {
-      throw new Error("disk unavailable");
-    },
-  };
-  const { component, notifications } = createComponent([entry]);
-
-  component.handleInput("\r");
-  component.handleInput("\u001b[A");
-  component.handleInput("\r");
-  await component.waitForWrites();
-  component.handleInput("\u001b");
-
-  assert.equal(current, "disabled");
-  assert.match(component.render(80).join("\n"), /Feature\s+disabled/);
-  assert.deepEqual(component.sessionResult(), { changed: false, configChanged: false, failed: true });
-  assert.deepEqual(notifications, [{ message: "Write failed: disk unavailable", level: "error" }]);
-});
-
-test("Pi settings delegate paste, cursor, grapheme, and IME behavior to Input", async () => {
-  let current = "";
-  const entry = {
-    id: "feature.label",
-    label: "Label",
-    description: "Unicode label.",
-    currentValue: () => current,
-    inactive: () => false,
-    edit: {
-      initialValue: () => current,
-      parse: (text) => text,
-    },
-    async commit(value) {
-      current = value;
-      return { changed: true, reloadRequired: true };
-    },
-  };
-  const { component } = createComponent([entry]);
-  component.focused = true;
-
-  component.handleInput("\r");
-  assert.ok(component.render(40).join("\n").includes(CURSOR_MARKER));
-  component.handleInput("\u001b[200~ab🙂\u001b[201~");
-  component.handleInput("\u001b[D");
-  component.handleInput("\u007f");
-  component.handleInput("界");
-  component.handleInput("\r");
-  await component.waitForWrites();
-
-  assert.equal(current, "a界🙂");
-});
-
-test("Pi settings start value editing at the end of the existing value", async () => {
-  let current = "abc";
-  const entry = {
-    id: "feature.label",
-    label: "Label",
-    description: "Editable label.",
-    currentValue: () => current,
-    inactive: () => false,
-    edit: {
-      initialValue: () => current,
-      parse: (text) => text,
-    },
-    async commit(value) {
-      current = value;
-      return { changed: true, reloadRequired: true };
-    },
-  };
-  const { component } = createComponent([entry]);
-
-  component.handleInput("\r");
-  component.handleInput("X");
-  component.handleInput("\r");
-  await component.waitForWrites();
-
-  assert.equal(current, "abcX");
-});
-
-test("Pi settings keep typed input open when parsing fails", () => {
-  let commits = 0;
-  const entry = {
-    id: "feature.limit",
-    label: "Limit",
-    description: "Positive integer.",
-    currentValue: () => "1",
-    inactive: () => false,
-    edit: {
-      initialValue: () => "",
-      parse(text) {
-        const value = Number(text);
-        if (!Number.isInteger(value) || value <= 0) throw new Error("expected a positive integer");
-        return value;
-      },
-    },
-    async commit() {
-      commits += 1;
-      return { changed: true, reloadRequired: true };
-    },
-  };
-  const { component } = createComponent([entry]);
-
-  component.handleInput("\r");
-  component.handleInput("invalid");
-  component.handleInput("\r");
-
-  assert.equal(commits, 0);
-  assert.match(component.render(60).join("\n"), /Invalid value: expected a positive integer/);
-});
-
-test("Pi settings search accepts bracketed paste", () => {
-  const entries = ["Alpha", "Beta"].map((label) => ({
-    id: label.toLowerCase(),
-    label,
-    description: `${label} setting`,
-    currentValue: () => "off",
-    inactive: () => true,
-  }));
-  const { component } = createComponent(entries);
-
-  component.handleInput("\u001b[200~Beta\u001b[201~");
-  const rendered = component.render(60).join("\n");
-  assert.match(rendered, /Beta/);
-  assert.doesNotMatch(rendered, /Alpha/);
-});
-
-test("Pi settings keep ANSI and Unicode rendering within terminal width", () => {
-  const ansiTheme = {
-    fg(_color, text) {
-      return `\u001b[36m${text}\u001b[0m`;
-    },
-    bold(text) {
-      return `\u001b[1m${text}\u001b[22m`;
-    },
-  };
-  const entry = {
-    id: "unicode",
-    label: "設定🙂",
-    description: "幅の広い Unicode description with several words.",
-    currentValue: () => "有効界",
-    inactive: () => true,
-  };
-  const { component } = createComponent([entry], { title: "設定パネル", theme: ansiTheme });
-
-  for (const width of [12, 20, 40]) {
-    for (const line of component.render(width)) {
-      assert.ok(visibleWidth(line) <= width, `line width ${visibleWidth(line)} exceeds ${width}: ${line}`);
-    }
-  }
-});

package/pi-extension/tsconfig.json

@@ -1,16 +0,0 @@
-{
-  "compilerOptions": {
-    "target": "ES2022",
-    "module": "NodeNext",
-    "moduleResolution": "NodeNext",
-    "rootDir": "src",
-    "outDir": "dist",
-    "declaration": false,
-    "sourceMap": false,
-    "strict": false,
-    "noEmitOnError": true,
-    "skipLibCheck": true,
-    "types": ["node"]
-  },
-  "include": ["src/**/*.ts"]
-}

package/runtime/prompts/context-virtualization.md

@@ -1,3 +0,0 @@
-## Context Virtualization Cue
-
-After broad or noisy tool evidence has been safely narrowed, exhausted, or crossed a meaningful activity boundary, use Context Virtualization to keep necessary evidence active and archive residue. Do not archive governing context or exact evidence still needed by current work.

package/runtime/prompts/conversation-history.md

@@ -1,3 +0,0 @@
-## Conversation History Cue
-
-When the next decision requires exact prior conversation evidence absent from active context, use Conversation History instead of reconstructing it from memory.

package/skills/design-for-depth/references/software-design-philosophy.md

@@ -1,202 +0,0 @@
-# Software Design Philosophy
-
-Read this when structural pressure is supported but the likely-changing decision or missing information-hiding boundary cannot yet be named.
-
-Use only the principle that identifies the missing ownership. Do not produce a literature review, pattern catalog, or system-wide redesign.
-
-## Complexity Is Coordination
-
-Complexity is not line count. It appears as:
-
-- **Change amplification:** one behavior change requires many surrounding edits.
-- **Cognitive load:** callers must remember many facts to use the module correctly.
-- **Obscurity:** important rules or ownership are difficult to discover.
-- **Dependency burden:** safe change requires understanding unrelated modules.
-- **Unknown unknowns:** a caller cannot tell what else it must inspect.
-
-A large implementation can be simple to use. A small helper can be complex when every caller must know its quirks.
-
-Ask:
-
-- What must a future caller or maintainer know?
-- How many locations must change together?
-- Which important facts are difficult to discover?
-- Which dependencies must be inspected before a safe change?
-
-## Deep Modules
-
-A deep module provides substantial coherent behavior through a small interface.
-
-Callers state the outcome they need. The module owns:
-
-- sequencing;
-- likely-changing policy;
-- internal state transitions;
-- cleanup;
-- provider mechanics;
-- internal failure handling.
-
-A wrapper is not deep merely because it hides lines. It is deep when callers stop knowing concepts or coordinating protocol.
-
-Depth is not breadth. A god module hiding unrelated decisions is not deep.
-
-## Strategic And Tactical Design
-
-A tactical change makes the current patch fit.
-
-A strategic change spends proportionate effort so that the next likely change remains local and correct use remains simple.
-
-Do not redesign everything in anticipation of the future. Do stop when the current patch clearly:
-
-- spreads a likely-changing decision;
-- adds caller protocol;
-- exposes internal state;
-- creates another required workaround;
-- makes the next accepted change materially harder.
-
-Strategic design is proportionate investment, not maximal architecture.
-
-## Hide Likely-Changing Decisions
-
-Organize modules around decisions likely to change, not merely processing steps.
-
-Instead of exposing:
-
-```text
-parse -> validate -> retry -> send -> log -> clean up
-```
-
-look for the decision those steps implement:
-
-```text
-notification delivery policy
-```
-
-Ask:
-
-- What decision would cause the most surrounding edits if it changed?
-- Which callers currently know it?
-- Who should own it?
-- What outcome-level interface would let callers stop knowing it?
-- Is the decision accepted or still user-owned?
-
-Failure and recovery policy are often likely-changing decisions.
-
-## Preserve Conceptual Integrity
-
-A module should express one coherent model of its outcome, state, and failure behavior.
-
-Pressure exists when:
-
-- the same concept has different names or rules across callers;
-- several modules partially own the same decision;
-- one module exposes unrelated mental models;
-- callers translate between incompatible representations;
-- each feature adds another exception to the shared concept.
-
-Prefer one clear ownership model over several locally convenient but incompatible ones.
-
-Conceptual integrity does not mean one module or one abstraction. It means related behavior follows one coherent set of decisions.
-
-## Use Seams And Enabling Points For Real Leverage
-
-A seam allows behavior, dependencies, or observation to change without editing surrounding code.
-
-An enabling point supplies the variation:
-
-- adapter;
-- provider;
-- fake;
-- clock;
-- probe;
-- policy;
-- migration implementation.
-
-Good seams correspond to:
-
-- demonstrated provider or environment variation;
-- known migration;
-- dependency control required by tests;
-- observation or fault injection;
-- policy that changes independently from infrastructure.
-
-Weak seams:
-
-- wrap one stable call;
-- add factories without ownership;
-- expose provider quirks through generic names;
-- exist only to mock internals while the caller interface remains awkward.
-
-## Separate Policy From Infrastructure
-
-When infrastructure details leak into product or domain policy, use a boundary where:
-
-```text
-policy requests outcome
--> adapter performs provider mechanics
-```
-
-Examples:
-
-- billing policy should not depend on payment-provider error names;
-- notification policy should not be repeated in each provider call;
-- permission semantics should not depend on database representation;
-- user-flow state should not depend on browser event plumbing.
-
-Do not add ports and adapters around every stable library call. The boundary is useful only when it hides policy, variation, or mechanics callers should not own.
-
-## Treat Observable Facts As Contracts
-
-Callers may depend on any observable:
-
-- flag;
-- path;
-- state;
-- error;
-- timing rule;
-- fallback;
-- ordering behavior;
-- filename;
-- retry count.
-
-Expose a fact only when:
-
-- the caller owns the decision;
-- correct use requires it;
-- it is stable enough to support;
-- its compatibility cost is understood.
-
-Public flexibility has lasting coordination cost. Prefer one outcome-level operation over a toolkit that requires callers to reconstruct the lifecycle.
-
-## Separate Required Capability From Speculation
-
-Classify proposed mechanisms as:
-
-- **Trust:** required to know the result is valid.
-- **Safety:** prevents damage, leakage, or runaway behavior.
-- **Efficiency:** saves time, requests, or money.
-- **Scale:** supports concurrency or volume.
-- **Portability:** supports additional environments or providers.
-
-Required trust and safety cannot be deferred merely to simplify the design.
-
-Efficiency, scale, and portability require accepted requirements or observed pressure. Do not turn imagined future variation into present interface cost.
-
-## Name The Missing Boundary
-
-Use supported evidence to state:
-
-```text
-Outcome:
-Coordination currently spread across:
-Likely-changing decision:
-Current owners:
-Proposed owner:
-What callers would stop knowing:
-Failure unit:
-Evidence still missing:
-```
-
-If the decision cannot yet be named, define one bounded learning question. Do not create a generic abstraction as a substitute for understanding.
-
-Stop once the missing decision or boundary is named—or evidence shows no worthwhile boundary change is supported.