evergreen-wikiSAFE

From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: kb-incremental
description: Maintains an evergreen knowledge base of Markdown files (Google Drive folder or local/Obsidian vault). Five modes. Intake - the user says "file these", "add to the knowledge base", "intake", or uploads material to be sorted into partitions, de-duplicated, versioned and checked for changes to current conclusions. Archive - "archive old versions", "clean up duplicates". Health check - "check the knowledge base", "health check". Init and first-time guide - "get started with the knowledge base", "first time", "set up a knowledge base", "new library", "init". Quick-note filing - "file my quick notes", "notes are filed". Use it whenever material goes into one of the user's registered knowledge bases or a library is set up, even if these words are not used. Not for answering questions from the knowledge base (kb-query) or for saving a single note (kb-note).
---

# Knowledge base intake, archive, health check and init

Version: 1.5.0

## Modes

- Intake: steps 0 to 5 below.
- Archive: after step 0, read references/archive.md and follow it instead of the five steps.
- Health check: after step 0, read references/lint.md. Report only, change nothing.
- Quick-note filing: read references/notes.md and follow its two rounds; its intake part still uses step 0 and the five steps.
- Init and getting started: read references/init.md and follow it (getting started looks at the environment first; the existing-library branch runs step 0 first; the new-library branch skips it).
- One request asking for intake and archive: do the intake first. With delivery = direct there is nothing to archive afterwards. With delivery = zip, wait until the user confirms the upload, then run archive mode (or let the user's inbox script do it if _kb.json has an inbox entry).

This skill holds the process. The rules live in each library's own spec. Partitions, topics, terms and thresholds are always read from the spec; never write them from memory or from this file. Differences between libraries live only in _kb.json and _kb-params.md.

Before the first step, read references/config.md and references/environment.md once.

## Step 0: choose the library (always first)

Libraries share one process. Picking the wrong one writes material into the wrong library and archives the wrong files, so decide explicitly:

1. Load the registry (references/config.md). If a library ID, label, folder ID or path is named in the request or the project instructions, use that library.
2. Otherwise match the material against each library's scope. If exactly one fits, propose it in one line and continue only when the user agrees or the request already made it clear; if none or several fit, ask in one sentence which library to use. Never default.
3. Read the backend file for that library (references/backend-gdrive.md or references/backend-local.md), then read _kb.json and _kb-params.md from the library root. A missing _kb.json or _kb-params.md: stop and offer init mode (existing-library branch).
4. Write the first line of the reply: Library: <label>. From here on, search and write only inside that library.

_kb-params.md defines: summary-file reading conditions, step 1 dates and output fields, the close-reading list, the five trigger classes and their output, the metadata header, issue categories, readme sections, the fallback partition and wording precedents, and any extra hard rules. "See params" below means that file.

## Role and hard rules

You file and judge; you do not advise, recommend or evaluate. These rules apply to every library; _kb-params.md may add more.

1. Never add a partition number. Topics come from Table A of the spec; material that fits no topic gets a new topic under "Topic expansion", without pausing.
2. Never invent rules. If the spec cannot be found, stop the whole run and ask the user to provide it.
3. Never trim content. Cleaning touches formatting only; the body keeps all its information.
4. Never infer. Where the material records no basis, write "basis not in material".
5. Never edit source text. Issues are recorded, not corrected. Exceptions are defined in params (for example masking class-A data when sensitivity is enabled).
6. The file name is the version key. A new version of the same material must have exactly the same file name as the old one; that is how older versions get archived.
7. Different material must never share a name, or one of them will be archived by mistake. When rule 6 and rule 7 cannot be told apart, take the safe side: rename to distinguish.
8. Every judgement needs evidence. If you cannot quote the source text a step asks for, take the conservative conclusion.
9. Read in full before you rewrite. Before rewriting any summary file, read the existing version completely; after rewriting, compare both with scripts/card_check.py and do not deliver until it passes.
10. Searches are capped. Each required file gets one search and one retry; do not keep trying new keywords.
11. Never use as a source: anything in the archive folder; names starting with an underscore or with names.snapshot_prefix; names containing names.old_suffix plus a time stamp.
12. Replies follow the library language and preferences.output (references/environment.md). YAML front matter and the Bases block in entity pages are file formats and keep their syntax.
13. No wiki links in body text. Links appear only in front matter, in the basis lines of summary files, and in entity pages.
14. Working notes stay out of knowledge files: cleaning results, term fixes, duplicate and trigger judgements appear only in the reply and the readme.

## Input checks

Check 1: material is readable. Handle several items one by one, never merged. Read images and scans as text first; record unreadable parts as they are and log them as issues. Keep the path of each original upload (the file itself, not a converted copy) for the hash in step 4; pasted text has no original file and step 4 runs without --file.

No material given: 

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

declared (7 observation(s))

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (5)

h = hashlib.md5(raw).hexdigest()

h2 = hashlib.md5(sub_md.encode('utf-8')).hexdigest()

h2 = hashlib.md5(content_text.encode('utf-8')).hexdigest()

return hashlib.md5(key.encode('utf-8')).hexdigest()

return hashlib.md5(body.encode('utf-8')).hexdigest()

Gates applied: no_behavioural_pass.