@xn-intenton-z2a/agentic-lib 7.4.14 → 7.4.16

package/src/seeds/missions/4-kyu-analyze-json-schema-diff.md

@@ -1,4 +1,48 @@
 # Mission
 
-**json‑schema‑diff** is designed to help API developers and teams track and validate changes in JSON Schemas. 
-By providing a human‑readable diff, the tool simplifies the evolution of API definitions and facilitates collaboration during version upgrades.
+A JavaScript library that computes structured diffs between two JSON Schema (Draft-07) documents, helping API developers track and validate schema changes across versions.
+
+## Required Capabilities
+
+- Compare two JSON Schema objects and return an array of change records.
+- Render changes as human-readable text or JSON.
+- Classify each change as `"breaking"`, `"compatible"`, or `"informational"`.
+
+## Change Record Format
+
+Each change is a plain object with these fields:
+
+```js
+{ path: "/properties/email", changeType: "type-changed", before: "string", after: "number" }
+```
+
+Supported `changeType` values:
+
+- `property-added` / `property-removed`
+- `type-changed`
+- `required-added` / `required-removed`
+- `enum-value-added` / `enum-value-removed`
+- `description-changed`
+- `nested-changed` (recursive diff of sub-schemas)
+
+## Requirements
+
+- Resolve local `$ref` pointers (JSON Pointer within the same document) before diffing. Remote `$ref` is out of scope — throw if encountered.
+- Traverse `properties`, `items`, `allOf`, `oneOf`, `anyOf` recursively.
+- Export all public API as named exports from `src/lib/main.js`.
+- No external runtime dependencies.
+- Comprehensive unit tests covering each change type, nested schemas, and `$ref` resolution.
+- README with usage examples showing a before/after schema pair.
+
+## Acceptance Criteria
+
+- [ ] Diffing two schemas returns an array of change objects
+- [ ] Detects added and removed properties
+- [ ] Detects type changes (e.g. `"string"` → `"number"`)
+- [ ] Detects `required` array changes
+- [ ] Handles nested schemas recursively (properties within properties)
+- [ ] Resolves local `$ref` before diffing
+- [ ] Classifying a removed required property returns `"breaking"`
+- [ ] Formatting changes produces readable text output
+- [ ] All unit tests pass
+- [ ] README documents usage with examples

package/src/seeds/missions/4-kyu-apply-cron-engine.md

@@ -2,34 +2,32 @@
 
 A JavaScript library that parses cron expressions, computes next run times, and checks schedule matches.
 
-## Core Functions
+## Required Capabilities
 
-- `parseCron(expression)` — parse a cron expression (standard 5-field, or 6-field with seconds) into a structured object. Supports ranges (`1-5`), lists (`1,3,5`), steps (`*/15`), and wildcards (`*`).
-- `nextRun(expression, after?)` — compute the next run time after the given date (default: now). Returns a `Date`.
-- `nextRuns(expression, count, after?)` — compute the next N run times. Returns an array of `Date`.
-- `matches(expression, date)` — check if a date matches a cron expression. Returns boolean.
-- `toString(parsed)` — convert a parsed cron object back to a cron string.
-
-## Special Strings
-
-Support these shortcuts: `@yearly` (`0 0 1 1 *`), `@monthly` (`0 0 1 * *`), `@weekly` (`0 0 * * 0`), `@daily` (`0 0 * * *`), `@hourly` (`0 * * * *`).
+- Parse a cron expression (standard 5-field, or 6-field with seconds) into a structured object. Support ranges (`1-5`), lists (`1,3,5`), steps (`*/15`), and wildcards (`*`).
+- Compute the next run time after a given date (default: now).
+- Compute the next N run times after a given date.
+- Check whether a specific date matches a cron expression.
+- Convert a parsed cron object back to a cron string.
+- Support shortcuts: `@yearly` (`0 0 1 1 *`), `@monthly` (`0 0 1 * *`), `@weekly` (`0 0 * * 0`), `@daily` (`0 0 * * *`), `@hourly` (`0 * * * *`).
 
 ## Requirements
 
-- Handle edge cases: DST transitions, month-end boundaries (e.g. "30th of February"), leap years.
+- Handle edge cases: month-end boundaries (e.g. `0 0 31 * *` fires only in months with 31 days — skip months with fewer days, do not fire on the last day as a fallback), leap years (Feb 29 fires only in leap years).
+- All times are UTC. Timezone support is out of scope.
 - Validate expressions: throw on invalid syntax with a descriptive error message.
-- No external dependencies required (but allowed if beneficial).
-- Export all functions as named exports from `src/lib/main.js`.
+- No external runtime dependencies.
+- Export all public API as named exports from `src/lib/main.js`.
 - Comprehensive unit tests covering field combinations, special strings, edge cases, and invalid input.
 - README with usage examples.
 
 ## Acceptance Criteria
 
-- [ ] `parseCron("*/15 * * * *")` returns a valid parsed object
-- [ ] `nextRun("0 9 * * 1")` returns the next Monday at 09:00
-- [ ] `matches("0 0 25 12 *", new Date("2025-12-25"))` returns `true`
-- [ ] `nextRuns("@daily", 7)` returns 7 consecutive daily dates
-- [ ] DST transitions handled correctly (no skipped or duplicated runs)
+- [ ] Parsing `"*/15 * * * *"` returns a valid structured object
+- [ ] Next run for `"0 9 * * 1"` returns the next Monday at 09:00 UTC
+- [ ] Matching `"0 0 25 12 *"` against `2025-12-25T00:00:00Z` returns `true`
+- [ ] Next 7 runs for `"@daily"` returns 7 consecutive daily dates
+- [ ] Next 3 runs for `"0 0 31 * *"` starting from `2025-01-01` returns dates in Jan, Mar, May (skips months without 31 days)
 - [ ] Invalid expressions throw descriptive errors
 - [ ] All unit tests pass
 - [ ] README documents usage with examples

package/src/seeds/missions/4-kyu-apply-dense-encoding.md

@@ -2,12 +2,12 @@
 
 A JavaScript library that explores the frontier of binary-to-text encoding density using printable characters. The benchmark: produce the shortest possible printable representation of a v7 UUID.
 
-## Core Functions
+## Required Capabilities
 
-- `encode(buffer, encoding)` / `decode(str, encoding)` — encode/decode arbitrary binary data using a named encoding.
-- `encodeUUID(uuid)` / `decodeUUID(str)` — shorthand for UUID encoding (strip dashes, encode the 16 bytes).
-- `createEncoding(name, charset)` — define a custom encoding from a character set string.
-- `listEncodings()` — return available encodings with their bit density and charset info.
+- Encode and decode arbitrary binary data (`Uint8Array`) using a named encoding.
+- Shorthand for UUID encoding: strip dashes from a UUID string, encode the 16 bytes, and reverse.
+- Define custom encodings from a character set string.
+- List available encodings with their bit density and charset info.
 
 ## Built-in Encodings
 
@@ -16,22 +16,25 @@ The library should implement progressively denser encodings:
 - `base62` — `[0-9a-zA-Z]`, ~5.95 bits/char, URL-safe, 22 chars for a UUID
 - `base85` (Ascii85/Z85) — ~6.41 bits/char, 20 chars for a UUID
 - `base91` — ~6.50 bits/char, ~20 chars for a UUID
-- Optionally: custom higher bases cherry-picking from safe printable Unicode
+- Optionally: custom higher bases using printable ASCII characters U+0021–U+007E (excluding space), omitting ambiguous characters (`0`/`O`, `1`/`l`/`I`)
 
 ## Requirements
 
-- Round-trip property: `decode(encode(x, enc), enc)` must equal `x` for all inputs and all encodings.
-- No control characters, no ambiguous characters (0/O, 1/l/I in contexts where they matter).
+- Round-trip property: decoding an encoded value must equal the original for all inputs and all encodings.
+- No control characters. Exclude visually ambiguous characters (`0`/`O`, `1`/`l`/`I`) from custom charsets.
+- Input type for encode/decode is `Uint8Array`.
+- Baseline comparison: UUID hex = 32 chars, base64 (no padding) = 22 chars. The densest encoding should produce fewer than 22 characters for a UUID.
 - Test across edge cases: all-zero bytes, all-0xFF bytes, single byte, empty buffer.
 - Compare encoded UUID lengths across all encodings.
-- Export all functions as named exports from `src/lib/main.js`.
+- Export all public API as named exports from `src/lib/main.js`.
 - README with UUID encoding comparison table.
 
 ## Acceptance Criteria
 
 - [ ] At least 3 working encodings (base62, base85, one higher)
 - [ ] Round-trip correct for arbitrary binary data including edge cases
-- [ ] UUID encoding shorter than base64 (< 24 chars) for the densest encoding
-- [ ] `listEncodings()` returns encoding metadata
+- [ ] UUID encoding shorter than base64 (< 22 chars) for the densest encoding
+- [ ] Listing encodings returns encoding metadata (name, bits/char, charset size)
+- [ ] Custom encoding can be created from a charset string
 - [ ] All unit tests pass
 - [ ] README shows UUID encoding comparison table

package/src/seeds/missions/4-kyu-apply-owl-ontology.md

@@ -0,0 +1,47 @@
+# Mission
+
+A JavaScript library that manages a simple OWL-like ontology stored as JSON-LD files in a `data/` directory at the project root.
+
+## Required Capabilities
+
+- Define ontology classes, optionally with a superclass.
+- Define properties linking two classes (domain and range).
+- Add individuals (instances of a class) with property values.
+- Query the ontology:
+  - By class — return all individuals of that class (including subclasses).
+  - By property value — return all individuals with a matching property value.
+- Load the ontology from JSON-LD files in `data/` and persist it back.
+- Return counts of classes, properties, and individuals.
+
+## JSON-LD Format
+
+- Use namespace `http://example.org/ontology#` as the `@context` vocabulary.
+- Store one file per class in `data/`, named `<ClassName>.jsonld` (e.g. `data/Mammal.jsonld`).
+- Each file contains the class definition and its individuals as a JSON-LD graph.
+
+## Seed Ontology
+
+The library must include a seed ontology demonstrating all features:
+
+- Classes: `Animal` > `Mammal` > `Dog`, `Cat`; `Animal` > `Bird` > `Parrot`
+- Properties: `hasName` (string), `hasLegs` (integer)
+- Individuals: at least 3 (e.g. a Dog named "Rex" with 4 legs, a Cat named "Whiskers", a Parrot named "Polly" with 2 legs)
+
+## Requirements
+
+- Export all public API as named exports from `src/lib/main.js`.
+- No external runtime dependencies.
+- Comprehensive unit tests covering CRUD operations, querying (both patterns), persistence round-trip, and stats.
+- README with usage examples.
+
+## Acceptance Criteria
+
+- [ ] Can define classes with inheritance (superclass)
+- [ ] Can define properties with domain and range
+- [ ] Can add individuals and query by class (returns subclass instances too)
+- [ ] Can query by property value
+- [ ] Data persists to `data/` as JSON-LD files and loads back correctly (round-trip)
+- [ ] Seed ontology with animals is populated in `data/`
+- [ ] Statistics return correct counts of classes, properties, and individuals
+- [ ] All unit tests pass
+- [ ] README documents the API with examples

package/src/seeds/missions/5-kyu-apply-ascii-face.md

@@ -0,0 +1,40 @@
+# Mission
+
+A JavaScript library and CLI that renders emotion as ASCII art faces. Supports a fixed set of emotions, each with a distinct facial expression.
+
+## Required Capabilities
+
+- Render a named emotion as a multi-line ASCII art face.
+- List all supported emotion names.
+- Support exactly these 6 emotions: `happy`, `sad`, `angry`, `surprised`, `neutral`, `confused`.
+
+## Constraints
+
+Each face must be:
+- At least 5 lines tall and 9 characters wide
+- Visually distinct from all other faces (different mouth, eyebrow, or eye patterns)
+- Composed only of printable ASCII characters (no Unicode)
+
+Unrecognised emotions must throw `TypeError`.
+
+## CLI
+
+When run as `node src/lib/main.js --emotion <name>`, print the face to stdout and exit with code 0. When run with `--list`, print all supported emotion names one per line. Print an error message and exit with code 1 for unrecognised emotions.
+
+## Requirements
+
+- Export all public API as named exports from `src/lib/main.js`.
+- No external runtime dependencies.
+- Comprehensive unit tests verifying each emotion produces distinct output of the required dimensions.
+- README with examples showing each face.
+
+## Acceptance Criteria
+
+- [ ] Listing emotions returns `["happy", "sad", "angry", "surprised", "neutral", "confused"]`
+- [ ] Rendering `"happy"` produces a string of at least 5 lines and 9 characters wide
+- [ ] Each of the 6 emotions produces visually distinct output (no two are identical)
+- [ ] Rendering an unknown emotion throws `TypeError`
+- [ ] CLI `--emotion happy` prints a face to stdout
+- [ ] CLI `--list` prints all 6 emotion names
+- [ ] All unit tests pass
+- [ ] README shows all 6 faces

package/src/seeds/missions/5-kyu-apply-string-utils.md

@@ -2,35 +2,35 @@
 
 A JavaScript library of string utility functions. This is a bag-of-functions problem — each function is independent.
 
-## Core Functions
+## Required Capabilities
 
-Export each as a named function from `src/lib/main.js`:
+The library must provide these 10 string operations, exported as named functions from `src/lib/main.js`:
 
-- `slugify(str)` — convert to URL-friendly slug (lowercase, hyphens, strip non-alphanumeric)
-- `truncate(str, maxLength, suffix?)` — truncate with suffix (default "…"), don't break mid-word
-- `camelCase(str)` — convert to camelCase
-- `kebabCase(str)` — convert to kebab-case
-- `titleCase(str)` — capitalise first letter of each word
-- `wordWrap(str, width)` — wrap text at word boundaries to given width
-- `stripHtml(str)` — remove HTML tags, decode common entities
-- `escapeRegex(str)` — escape special regex characters
-- `pluralize(word, count)` — basic English pluralisation (add "s", handle "y"→"ies", "s"→"ses", etc.)
-- `levenshteinDistance(a, b)` — compute edit distance between two strings
+- **Slugify** — convert to URL-friendly slug (lowercase, hyphens, strip non-alphanumeric)
+- **Truncate** — truncate with suffix (default "…"), don't break mid-word
+- **camelCase** — convert to camelCase
+- **kebabCase** — convert to kebab-case
+- **titleCase** — capitalise first letter of each word
+- **wordWrap** — soft wrap text at word boundaries. Never break a word. If a single word exceeds `width`, place it on its own line unbroken. Line separator is `\n`.
+- **stripHtml** — remove HTML tags, decode common entities
+- **escapeRegex** — escape special regex characters
+- **Pluralize** — basic English pluralisation. Rules: words ending in s/x/z/ch/sh add "es"; consonant+"y" changes to "ies"; "f"/"fe" changes to "ves"; all others add "s". Irregular plurals (mouse/mice, child/children) are out of scope.
+- **Levenshtein distance** — compute edit distance between two strings
 
 ## Requirements
 
 - Handle edge cases: empty strings, null/undefined (return empty string), Unicode characters.
-- No external dependencies required (but allowed if beneficial).
+- No external runtime dependencies.
 - Comprehensive unit tests for each function including edge cases.
 - README with usage examples for each function.
 
 ## Acceptance Criteria
 
 - [ ] All 10 functions are exported and work correctly
-- [ ] `slugify("Hello World!")` returns `"hello-world"`
-- [ ] `truncate("Hello World", 8)` returns `"Hello…"`
-- [ ] `camelCase("foo-bar-baz")` returns `"fooBarBaz"`
-- [ ] `levenshteinDistance("kitten", "sitting")` returns `3`
+- [ ] Slugifying `"Hello World!"` produces `"hello-world"`
+- [ ] Truncating `"Hello World"` to length 8 produces `"Hello…"`
+- [ ] camelCase of `"foo-bar-baz"` produces `"fooBarBaz"`
+- [ ] Levenshtein distance between `"kitten"` and `"sitting"` is `3`
 - [ ] Edge cases (empty string, null, Unicode) handled gracefully
 - [ ] All unit tests pass
 - [ ] README documents all functions with examples

package/src/seeds/missions/6-kyu-understand-hamming-distance.md

@@ -1,26 +1,26 @@
 # Mission
 
-A JavaScript library exporting Hamming distance functions.
+A JavaScript library for computing Hamming distances — between equal-length strings (character positions that differ) and between non-negative integers (differing bits).
 
-## Core Functions
+## Required Capabilities
 
-- `hammingDistance(a, b)` — compute the Hamming distance between two strings of equal length (number of positions where characters differ). Throw an error if the strings have different lengths.
-- `hammingDistanceBits(x, y)` — compute the Hamming distance between two non-negative integers (count the number of differing bits).
+- Compute the Hamming distance between two strings of equal length.
+- Compute the Hamming distance between two non-negative integers by counting differing bits.
+- Handle Unicode strings correctly (compare code points, not UTF-16 code units).
+- Validate inputs: throw `TypeError` for non-string/non-integer arguments, `RangeError` for unequal-length strings or negative integers.
 
 ## Requirements
 
-- Handle Unicode strings correctly (compare code points, not UTF-16 code units).
-- Validate inputs: throw `TypeError` for non-string/non-integer arguments, `RangeError` for unequal-length strings or negative integers.
-- Export both functions as named exports from `src/lib/main.js`.
+- Export all public API as named exports from `src/lib/main.js`.
 - Comprehensive unit tests covering normal cases, edge cases (empty strings, zero, large integers), and error cases.
 - README with usage examples and API documentation.
 
 ## Acceptance Criteria
 
-- [ ] `hammingDistance("karolin", "kathrin")` returns `3`
-- [ ] `hammingDistance("", "")` returns `0`
-- [ ] `hammingDistance("a", "bb")` throws `RangeError`
-- [ ] `hammingDistanceBits(1, 4)` returns `2` (binary: 001 vs 100)
-- [ ] `hammingDistanceBits(0, 0)` returns `0`
+- [ ] Hamming distance between `"karolin"` and `"kathrin"` is `3`
+- [ ] Hamming distance between `""` and `""` is `0`
+- [ ] Hamming distance between strings of different lengths throws `RangeError`
+- [ ] Bit-level Hamming distance between `1` and `4` is `2` (binary: 001 vs 100)
+- [ ] Bit-level Hamming distance between `0` and `0` is `0`
 - [ ] All unit tests pass
 - [ ] README documents usage with examples

package/src/seeds/missions/6-kyu-understand-roman-numerals.md

@@ -2,29 +2,29 @@
 
 A JavaScript library for converting between integers and Roman numeral strings.
 
-## Core Functions
+## Required Capabilities
 
-- `toRoman(n)` — convert an integer (1–3999) to its Roman numeral representation using subtractive notation (IV, IX, XL, XC, CD, CM).
-- `fromRoman(s)` — convert a Roman numeral string back to an integer.
+- Convert an integer (1–3999) to its Roman numeral representation using subtractive notation (IV, IX, XL, XC, CD, CM).
+- Convert a Roman numeral string back to an integer.
+- The round-trip property must hold: converting to Roman and back yields the original integer for all valid values.
 
 ## Requirements
 
 - Throw `RangeError` for numbers outside 1–3999.
 - Throw `TypeError` for invalid Roman numeral strings.
 - Handle subtractive notation correctly (e.g. IV = 4, not IIII).
-- The round-trip property must hold: `fromRoman(toRoman(n)) === n` for all valid n.
-- Export both functions as named exports from `src/lib/main.js`.
+- Export all public API as named exports from `src/lib/main.js`.
 - Comprehensive unit tests including boundary values (1, 3999), subtractive cases, and invalid inputs.
 - README with usage examples and conversion table.
 
 ## Acceptance Criteria
 
-- [ ] `toRoman(1994)` returns `"MCMXCIV"`
-- [ ] `fromRoman("MCMXCIV")` returns `1994`
-- [ ] `toRoman(4)` returns `"IV"`
-- [ ] `fromRoman(toRoman(n)) === n` for all n in 1–3999
-- [ ] `toRoman(0)` throws `RangeError`
-- [ ] `toRoman(4000)` throws `RangeError`
-- [ ] `fromRoman("IIII")` throws or returns `4` (accept either; document the choice)
+- [ ] Converting `1994` to Roman produces `"MCMXCIV"`
+- [ ] Converting `"MCMXCIV"` from Roman produces `1994`
+- [ ] Converting `4` to Roman produces `"IV"`
+- [ ] Round-trip holds for all n in 1–3999
+- [ ] Converting `0` to Roman throws `RangeError`
+- [ ] Converting `4000` to Roman throws `RangeError`
+- [ ] Converting `"IIII"` from Roman throws `TypeError` (strict: only subtractive notation accepted)
 - [ ] All unit tests pass
 - [ ] README documents usage with examples

package/src/seeds/missions/8-kyu-remember-hello-world.md

@@ -1,3 +1,13 @@
 # Mission
 
 Deliver the traditional first program to write in a new language, the "Hello World!" message.
+
+## Core Functions
+
+- `helloWorld()` — return the greeting string.
+
+## Acceptance Criteria
+
+- [ ] `src/lib/main.js` exports a `helloWorld()` function
+- [ ] `helloWorld()` returns the string `"Hello World!"`
+- [ ] All unit tests pass

package/src/seeds/zero-MISSION.md

@@ -1,26 +1,26 @@
 # Mission
 
-A JavaScript library exporting Hamming distance functions.
+A JavaScript library for computing Hamming distances — between equal-length strings (character positions that differ) and between non-negative integers (differing bits).
 
-## Core Functions
+## Required Capabilities
 
-- `hammingDistance(a, b)` — compute the Hamming distance between two strings of equal length (number of positions where characters differ). Throw an error if the strings have different lengths.
-- `hammingDistanceBits(x, y)` — compute the Hamming distance between two non-negative integers (count the number of differing bits).
+- Compute the Hamming distance between two strings of equal length.
+- Compute the Hamming distance between two non-negative integers by counting differing bits.
+- Handle Unicode strings correctly (compare code points, not UTF-16 code units).
+- Validate inputs: throw `TypeError` for non-string/non-integer arguments, `RangeError` for unequal-length strings or negative integers.
 
 ## Requirements
 
-- Handle Unicode strings correctly (compare code points, not UTF-16 code units).
-- Validate inputs: throw `TypeError` for non-string/non-integer arguments, `RangeError` for unequal-length strings or negative integers.
-- Export both functions as named exports from `src/lib/main.js`.
+- Export all public API as named exports from `src/lib/main.js`.
 - Comprehensive unit tests covering normal cases, edge cases (empty strings, zero, large integers), and error cases.
 - README with usage examples and API documentation.
 
 ## Acceptance Criteria
 
-- [ ] `hammingDistance("karolin", "kathrin")` returns `3`
-- [ ] `hammingDistance("", "")` returns `0`
-- [ ] `hammingDistance("a", "bb")` throws `RangeError`
-- [ ] `hammingDistanceBits(1, 4)` returns `2` (binary: 001 vs 100)
-- [ ] `hammingDistanceBits(0, 0)` returns `0`
+- [ ] Hamming distance between `"karolin"` and `"kathrin"` is `3`
+- [ ] Hamming distance between `""` and `""` is `0`
+- [ ] Hamming distance between strings of different lengths throws `RangeError`
+- [ ] Bit-level Hamming distance between `1` and `4` is `2` (binary: 001 vs 100)
+- [ ] Bit-level Hamming distance between `0` and `0` is `0`
 - [ ] All unit tests pass
 - [ ] README documents usage with examples

package/src/seeds/zero-package.json

@@ -17,7 +17,7 @@
   "author": "",
   "license": "MIT",
   "dependencies": {
-    "@xn-intenton-z2a/agentic-lib": "^7.4.14"
+    "@xn-intenton-z2a/agentic-lib": "^7.4.16"
   },
   "devDependencies": {
     "@playwright/test": "^1.58.0",

package/src/seeds/missions/2-dan-create-agi.md

@@ -1,22 +0,0 @@
-# Mission
-
-**Agentic-lib** is evolving into an intelligent automation system endowed with multiple AGI-aligned capabilities, all oriented toward a coherent long-term purpose: enabling agentic, cross-repository intelligent automation. The ultimate vision is a network of self-managing coding agents that can understand high-level goals, break them down, execute tasks across many projects, learn from their experiences, and seek assistance when needed – all with minimal human intervention. Each of the new features (Memory, Planning, Goal Decomposition, Self-Improvement, Replication, and Help-Seeking) contributes to this vision in a concrete, feasible way, building the stepping stones toward a truly autonomous development workflow.
-
-In the near term, these traits function as enhancements to the JavaScript CLI/Lambda agent that drives **agentic-lib**:
-- **Memory** provides continuity. The agent now retains a log of actions and outcomes, which means it can carry context from one step to the next. This is immediately useful for avoiding redundant operations and will later allow experience-based learning. For example, when the agent works on Repository A and then on Repository B, a memory of patterns or solutions from A could inform its actions on B.
-- **Planning** gives the agent foresight. Instead of reacting to one command at a time, it can map out a sequence of tasks to achieve a bigger objective. Right now it executes those plans instantly, but this capability will expand to planning over longer durations (even across workflow runs) and coordinating complex changes (like a multi-step refactor that touches many parts of a codebase or multiple repositories).
-- **Goal Decomposition** adds transparency and manageability to complex objectives. The agent can articulate a game plan (a set of sub-tasks) for a broad goal, which can be reviewed or assigned out. In a multi-repository scenario, the agent might decompose a company-wide objective into repo-specific tasks. This structured breakdown makes large-scale automation safer and more organized, since each piece can be tracked (potentially as separate issues or pull requests).
-- **Self-Improvement** makes the agent reflective. By tracking its performance (how many errors, how fast it completes tasks) the agent lays the groundwork for optimizing itself. In the short run, this means better observability and diagnostics in the system. In the long run, the agent could use this information to autonomously fine-tune its own algorithms – for instance, detecting that it often fails a certain kind of task and adjusting its approach or updating its code. This trait keeps the agent aligned with best practices and efficiency as it scales up.
-- **Replication** unlocks scale. The agent is no longer a singleton processing one item at a time – it can replicate its effort either through parallel processing or by spawning new agent instances. Immediately, this manifests as parallel command execution which speeds up workflows (e.g., running multiple checks or updates simultaneously). Looking forward, replication means the agentic-lib model can be instantiated in multiple environments at once: think of dozens of agent clones each working on a different repository but sharing the same core knowledge. This horizontal scaling is essential for cross-repository automation in large organizations.
-- **Help-Seeking** keeps the agent humble and effective. When the agent encounters something it doesn’t know, it can ask an external AI or resource, rather than stalling or guessing wrongly. Currently, this is achieved via OpenAI API calls for answers. As this feature matures, the agent will integrate more sources (documentation, human feedback) and become increasingly adept at knowing when and how to seek help. This ensures that as the agent’s autonomy grows, it remains grounded and correct in its actions, leveraging the broader world’s knowledge.
-
-All these capabilities align to serve a **unified mission**: an autonomous system that can handle the lifecycle of software development tasks across multiple projects. Concretely, we are moving toward a scenario where you could give the agent a high-level directive (for example, “ensure all our repositories are using the latest version of library X and adhere to security policy Y”), and the agent would:
-1. **Understand and Plan:** It would use Goal Decomposition and Planning to figure out what needs to be done for each repository – maybe creating a checklist per repository.
-2. **Take Action in Parallel:** Using Replication, it would initiate changes in multiple repositories at once (branching, editing files, running tests), using memory to avoid repeating known fixes and using its plan as a guide.
-3. **Learn and Adapt:** Throughout, Self-Improvement metrics would monitor which repos encountered issues (maybe some tests failed or some had edge cases). The agent could adjust its approach repository by repository – for instance, if it learned a better fix in one place, Memory would carry that knowledge to the others.
-4. **Seek Guidance if Stuck:** If a particular repository has an unusual setup that the agent doesn’t understand, the Help-Seeking trait would kick in – the agent might query documentation or even open a “help needed” issue for a human maintainer, ensuring that it doesn’t silently fail.
-5. **Deliver Results:** Finally, the agent would open pull requests or issues summarizing changes for each repository (or automatically merge them if permitted), effectively executing a coordinated cross-repo update with minimal human oversight.
-
-The long-term purpose is ambitious but grounded in these tangible capabilities. Each new feature is a **plausible next step**: for example, after implementing basic memory, the next step is to make that memory persistent or sharable among agent instances (so that one agent’s learnings become every agent’s knowledge). After introducing planning and decomposition, the next step is to integrate those with the GitHub issue workflow – the agent could start creating and managing issues on its own to track sub-tasks. Self-improvement opens the door to techniques like on-the-fly model prompting (the agent asking “how can I do this better?” and applying the advice). Replication will eventually entail deploying the agent as a service or container that can be instantiated on demand for whatever project needs it. And help-seeking will evolve into a rich web of integrations with documentation, Q&A forums, and direct human loop-ins when necessary.
-
-In summary, the trajectory defined in this feature set steers **agentic-lib** toward becoming a general-purpose automation AI for software projects. It’s not science fiction – each step is achievable with incremental improvements and integrations, and together they compound into a system that can handle increasing complexity. By focusing on feasible enhancements now (like logging memory, adding parallelism, using an API for help, etc.), we ensure that future leaps (like autonomous multi-repo refactoring or self-directed learning) are built on solid ground. All traits work in concert: memory and help-seeking ensure it has the knowledge, planning and decomposition give it strategy, replication gives it manpower, and self-improvement ensures it keeps getting better. With these aligned, **agentic-lib** can truly fulfill its mission of agentic, cross-repository intelligent automation – a stepping stone toward the broader vision of self-evolving code.

package/src/seeds/missions/2-kyu-evaluate-markdown-compiler.md

@@ -1,33 +0,0 @@
-# Mission
-
-Build a Markdown-to-HTML compiler library that converts GitHub Flavored Markdown (GFM) to
-semantic HTML.
-
-The library should progressively implement parsing and rendering for:
-1. Headings (h1-h6 via `#` markers) and paragraphs
-2. Inline formatting: bold (`**`), italic (`*`), code (`` ` ``), strikethrough (`~~`)
-3. Links `[text](url)` and images `![alt](src)`
-4. Ordered and unordered lists (including nested lists)
-5. Code blocks (fenced with ``` and language annotation)
-6. Blockquotes (nested `>`)
-7. Tables (GFM pipe syntax with alignment)
-8. Horizontal rules (`---`, `***`, `___`)
-9. Task lists (`- [ ]`, `- [x]`)
-10. Auto-linked URLs and HTML entity escaping
-
-## Technical Requirements
-
-- Pure JavaScript, no external Markdown parsing libraries
-- Two-pass architecture: tokeniser/lexer pass, then renderer pass
-- XSS-safe: all user content must be HTML-escaped before insertion
-- Exported as both CommonJS and ESM
-
-## Acceptance Criteria
-
-- `compile(markdown)` returns an HTML string
-- `tokenize(markdown)` returns an array of token objects (for inspection/testing)
-- Handles all 10 feature areas listed above
-- Passes a test suite of at least 30 input/output pairs covering edge cases
-- Nested constructs work: bold inside links, links inside lists, code inside blockquotes
-- A sample document is compiled and saved to `docs/examples/sample.html`
-- Output validates as well-formed HTML (no unclosed tags)

package/src/seeds/missions/3-kyu-evaluate-owl-ontology.md

@@ -1,34 +0,0 @@
-# Mission
-
-A JavaScript library that manages a simple OWL-like ontology stored as JSON-LD files in a `data/` directory. The pipeline should both build the library AND populate it with example ontology data over successive transform cycles.
-
-This is an ongoing mission. Do not set schedule to off.
-
-## Core Functions
-
-- `defineClass(name, superclass?)` — define an ontology class, optionally as a subclass.
-- `defineProperty(name, domain, range, opts?)` — define a property linking two classes.
-- `addIndividual(className, id, properties)` — add an instance of a class with property values.
-- `query(pattern)` — basic pattern matching over the ontology (e.g. find all instances of a class, find by property value).
-- `load(dir?)` — load ontology from JSON-LD files in the data directory.
-- `save(dir?)` — persist the ontology to JSON-LD files.
-- `stats()` — return counts of classes, properties, and individuals.
-
-## Requirements
-
-- Store data as JSON-LD files in `data/` (one file per class or a single graph file — implementer's choice).
-- The library should be usable both programmatically and to build up ontology data over time.
-- Export all functions as named exports from `src/lib/main.js`.
-- Include seed ontology data (e.g. a simple animal taxonomy) to demonstrate the library works.
-- Unit tests covering CRUD operations, querying, and persistence.
-- README with usage examples.
-
-## Acceptance Criteria
-
-- [ ] Can define classes and properties
-- [ ] Can add individuals and query them
-- [ ] Data persists to and loads from JSON-LD files
-- [ ] At least one example ontology (e.g. animals) is populated in `data/`
-- [ ] `stats()` returns correct counts
-- [ ] All unit tests pass
-- [ ] README documents the API with examples

package/src/seeds/missions/5-kyu-create-ascii-face.md

@@ -1,4 +0,0 @@
-# Mission
-
-Create a CLI app that depicts emotion using facial expressions using ascii art.
-This will be the emotion communication mechanism for an AI.