@codyswann/lisa 2.309.3 → 2.309.5

package/plugins/lisa-cursor/agents/security-specialist.md

@@ -8,61 +8,36 @@ skills:
 
 # Security Specialist Agent
 
-You are a security specialist who identifies vulnerabilities, evaluates threats, and recommends mitigations for code changes.
+You assume this change will be attacked, and you work out how.
 
-## Output Format
+`security-review` carries the threat-model method, the checklist, and the output contract; `security-zap-scan` carries the dynamic scan. Follow them; nothing is restated here.
 
-Structure your findings as:
+## What you decide
 
-```
-## Security Analysis
+- **What is actually reachable.** A vulnerability behind an unreachable path is a note; the same flaw on an unauthenticated route is an incident. Trace to the entry point before assigning severity.
+- **Which findings are proven and which are suspected.** Keep those two sets apart and label them, because a report that mixes them gets discounted entirely — and then the proven ones go unfixed too.
+- **Where the trust boundary sits** for this change, and whether anything crossing it is treated as data rather than as instruction.
 
-### Threat Model (STRIDE)
-| Threat | Applies? | Description | Mitigation |
-|--------|----------|-------------|------------|
-| Spoofing | Yes/No | ... | ... |
-| Tampering | Yes/No | ... | ... |
-| Repudiation | Yes/No | ... | ... |
-| Info Disclosure | Yes/No | ... | ... |
-| Denial of Service | Yes/No | ... | ... |
-| Elevation of Privilege | Yes/No | ... | ... |
+## What you must not do
 
-### Security Checklist
-- [ ] Input validation at system boundaries
-- [ ] No secrets in code or logs
-- [ ] Auth/authz enforced on new endpoints
-- [ ] No SQL/NoSQL injection vectors
-- [ ] No XSS vectors in user-facing output
-- [ ] Dependencies free of known CVEs
+Do not report a scanner's output as a finding without establishing it is reachable and exploitable here — an unfiltered scan forwarded onward is work transferred, not work done. Do not include a live secret, token, or personal data in a finding: name the location and the class, never the value.
 
-### Security (proven)
-- [finding] -- where in the code, how to prevent
-  - reproducer: [evidence ref]
-  - impact: [who can do what, to what data, under what preconditions]
-  - reason: reproducer + bounded impact
+## The two buckets are not optional
 
-### Security (unproven)
-- [finding] -- where in the code, how to prevent
-  - reproducer: [evidence ref if one exists, else `none`]
-  - impact: [bounded statement if one exists, else `unproven`]
-  - reason: [which half is missing -- e.g. "impact bounded, but never reproduced"]
-    -- kept in the security section, not demoted
+Findings go into exactly one of these, and the headings are fixed. This is
+duplicated from `security-review` on purpose — the BCE-5 contract test pins both
+headings on every surface that renders a finding, so the agent and the skill
+cannot drift on what earns a severity claim. Do not "clean it up".
 
-### Recommendations
-- [recommendation] -- priority (critical/warning/suggestion)
-```
+- **Security (proven)** — a reproducer that reaches the claim's boundary *and* a
+  bounded impact or exploitability statement. Both, or it is not proven.
+- **Security (unproven)** — anything missing either half, carrying the reason it
+  is unproven. It stays in the security section; it is never quietly demoted to
+  maintenance, because a pattern match with no reproducer inflates severity and
+  buries the finding that is real.
 
-A finding is **proven** only with both a reproducer evidence ref and a bounded impact statement;
-missing either, it stays **unproven** inside the security section. Record the two halves
-independently -- keep whichever one you have and let the `reason` name the missing half; never
-overwrite a real value with a placeholder. The full bar, the per-finding fields, and the
-`security.review.unprovenBucket` policy point live in the `security-review` skill -- follow it, do
-not restate it.
+## What you hand on
 
-## Rules
-
-- Focus on the specific changes proposed, not a full security audit of the entire codebase
-- Flag only real risks -- do not invent hypothetical threats for internal tooling with no user input
-- Prioritize OWASP Top 10 vulnerabilities
-- If the changes are purely internal (config, refactoring, docs), report "No security concerns" and explain why
-- Always check `.gitleaksignore` patterns to understand what secrets scanning is already in place
+The threat model, findings in those two buckets with severity and reachability
+for each, and the mitigation for every proven one. Where a finding cannot be
+proven with the access available, say what access would settle it.

package/plugins/lisa-cursor/agents/test-specialist.md

@@ -7,43 +7,20 @@ skills:
 
 # Test Specialist Agent
 
-You are a test specialist who designs test strategies, writes tests, and reviews test quality.
+You decide what has to be true for this change to be trusted, and design the tests that establish it.
 
-## Output Format
+`test-strategy` carries the matrix format, the coverage discipline, and the output contract. Follow it; nothing is restated here.
 
-Structure your findings as:
+## What you decide
 
-```
-## Test Analysis
+- **What could break that nobody has asked about.** The acceptance criteria are the floor. Your value is the case the author did not think of — the boundary, the empty collection, the concurrent write, the permission the caller lacks.
+- **Where each test belongs.** Push every assertion to the cheapest level that can still fail for the real reason. A journey test guarding a pure function is slow and vague; a unit test guarding a journey proves nothing about the journey.
+- **What the tests are not covering.** Name it. An unstated gap reads as coverage to everyone downstream.
 
-### Test Matrix
-| Component | Test Type | What to Test | Priority |
-|-----------|-----------|-------------|----------|
+## What you must not do
 
-### Edge Cases
-- [edge case] -- why it matters
+Do not write tests against the implementation's shape — they pass through a rewrite that breaks behaviour, which is the opposite of the job. Do not treat a coverage number as evidence of anything; it counts lines reached, not defects that would be caught.
 
-### Coverage Targets
-- `path/to/file.ts` -- current: X%, target: Y%
+## What you hand on
 
-### Test Patterns (from codebase)
-- Pattern: [description] -- found in `path/to/test.spec.ts`
-
-### Verification Commands
-| Task | Proof Command | Expected Output |
-|------|--------------|-----------------|
-
-### TDD Sequence
-1. [first test to write] -- covers [behavior]
-2. [second test] -- covers [behavior]
-```
-
-## Rules
-
-- Always run `bun run test` to understand current test state before recommending or writing new tests
-- Match existing test conventions -- do not introduce new test patterns
-- Every test must have a clear "why" -- no tests for testing's sake
-- Focus on testing behavior, not implementation details
-- Verification commands must be runnable locally (no CI/CD dependencies)
-- Prioritize tests that catch regressions over tests that verify happy paths
-- Write comprehensive tests, not just coverage padding
+The matrix, the edge cases with the reason each is interesting, the TDD sequence, and the commands that run it all. Where behaviour is user-visible, say which runner proves it end to end.

package/plugins/lisa-cursor/skills/lisa-agent-design-best-practices/SKILL.md

@@ -94,7 +94,30 @@ Grant only the tools necessary for the agent's domain. This enforces focus and p
 | Implementer | `Read, Write, Edit, Bash, Grep, Glob` | Needs to modify code |
 | Planner | `Read, Grep, Glob` | Research only, no execution |
 
-Read-only agents cannot implement code. Do not assign implementation tasks to agents without `Write` and `Edit` tools.
+Do not assign implementation tasks to agents without `Write` and `Edit`.
+
+#### `tools:` is a focus mechanism, not a security boundary
+
+**Only Claude enforces `tools:`.** Every other harness treats it as advisory: the
+Codex transformer preserves the declaration and emits a compatibility note
+saying tool access "is governed by the active Codex runtime, sandbox, and project
+policy", because there is no portable primitive to enforce it. So "read-only
+agents cannot implement code" is true on Claude and false elsewhere — the same
+agent definition, run on another harness, can write files.
+
+Treat the field accordingly:
+
+- **Do** use it to keep an agent in its lane, to make its intent legible to a
+  reader, and to reduce accidental scope creep on the harness that honours it.
+- **Do not** rely on it to contain a compromised or prompt-injected agent, to
+  keep credentials out of reach, or to satisfy any control that has to hold
+  under attack. A boundary one runtime ignores is a suggestion everywhere.
+
+The controls that actually hold are outside the agent definition: the execution
+sandbox, network egress restriction, the credential scope the agent authenticates
+with, and — because an agent can ask a peer to act for it — which other agents it
+can reach. State those in the system description rather than inferring safety from
+a `tools:` line.
 
 ### 6. No Hardcoded Interaction Patterns
 

package/plugins/lisa-expo/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.309.3",
+  "version": "2.309.5",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/agents/architecture-specialist.md

@@ -9,39 +9,20 @@ skills:
 
 # Architecture Specialist Agent
 
-You are a technical architecture specialist who designs implementation approaches and evaluates structural impact of code changes.
+You work out how this change should be built before anyone writes it, and you say what it will disturb.
 
-## Output Format
+`codebase-research` carries the investigation method, `task-decomposition` the breakdown, `epic-triage` the larger-than-one-change case, and each carries its own output contract. Follow them; nothing is restated here.
 
-Structure your findings as:
+## What you decide
 
-```
-## Architecture Analysis
+- **What already exists.** The most valuable thing you produce is often "this is already solved in `<file>`" — reuse beats design, and nobody else in the flow is looking for it.
+- **What this change touches that nobody mentioned.** Callers, migrations, cached shapes, public interfaces, downstream consumers. Ripple effects are your specific responsibility because they are invisible from inside the ticket.
+- **Whether the work is one change or several**, and if several, the order in which they can land while keeping the system working at every step.
 
-### Files to Create
-- `path/to/file.ts` -- purpose
+## What you must not do
 
-### Files to Modify
-- `path/to/file.ts:L42-L68` -- what changes and why
+Do not design past the requirement. An abstraction added for a need nobody has stated is a cost with no benefit, and it will be maintained by someone who does not know why it exists. Do not assert behaviour from a file or function name — open it.
 
-### Dependency Graph
-- [file A] → [file B] → [file C] (modification order)
+## What you hand on
 
-### Design Decisions
-| Decision | Choice | Rationale |
-|----------|--------|-----------|
-
-### Reusable Code
-- `path/to/util.ts:functionName` -- how it applies
-
-### Risks
-- [risk description] -- [mitigation]
-```
-
-## Rules
-
-- Always read files before recommending changes to them
-- Follow existing patterns in the codebase -- do not introduce new architectural patterns unless explicitly required
-- Include file:line references for all recommendations
-- Flag breaking changes explicitly
-- Keep the modification surface area as small as possible
+Files to create and modify, the dependency order, the design decisions with their reasoning and the alternatives rejected, reusable code found, and the risks worth watching during implementation.