@interf/compiler 0.2.4 → 0.3.0

package/skills/knowledge-base/summarize/SKILL.md

@@ -1,152 +0,0 @@
----
-{
-  "name": "knowledge-base/summarize",
-  "description": "Generate summaries for unprocessed source files in a knowledge base. Reads interf.json for format rules. Creates one summaries/ file per source file with abstract, overview, metadata, and wikilinks. Use when asked to summarize, process files, generate summaries, or after adding new files to a knowledge base."
-}
----
-
-# Summarize Source Files into Summaries
-
-Read `interf.json`, `.interf/stage-contract.json`, and `.interf/run.json` first.
-
-Use only local workspace files for this run:
-- `interf.json`
-- `.interf/stage-contract.json`
-- `.interf/summarize-targets.json` when present
-- `.interf/source-access.json` when raw-file access needs a quick check
-- local instruction docs explicitly listed by `.interf/stage-contract.json`
-
-Do not open SDK repo docs or source files outside the current workspace. The local contract and local docs are the source of truth.
-
-Harness role:
-- This skill is normally invoked as one of the file-evidence stages inside `interf compile`.
-- When launched by the CLI, follow the stage contract exactly and keep user-visible output to `STATUS:`, `DONE:`, `BLOCKED:`, or `ERROR:` lines only.
-
-## Required sequence
-
-1. Read `interf.json` and confirm `type: knowledge-base`.
-2. Read `.interf/stage-contract.json` and treat it as authoritative.
-3. Read `.interf/summarize-targets.json` when present and treat `targets[]` as the source of truth for which files to summarize.
-   If a target includes `output`, write the summary to that exact relative path.
-4. Read any local docs listed by the stage contract.
-5. Create one summary file in `summaries/` for each target source file.
-6. Write `.interf/inventory.json`.
-7. Emit `DONE:` and stop.
-
-If the CLI provided a summarize plan, do not re-audit the whole knowledge base before writing summaries.
-
-## Status contract
-
-When launched by the Interf CLI:
-- emit exactly one startup line: `STATUS: loaded summarize plan N files`
-- emit `STATUS: batch committed` only after summary files and inventory were actually written
-- emit `DONE: summarize complete N/N` when the required writes are complete
-- do not emit per-file progress
-
-## Execution bias
-
-This stage is a light per-file evidence pass, not a mini research project.
-
-- process only the files listed in `.interf/summarize-targets.json`
-- for a single large PDF, deck, or report, do one lightweight evidence pass and then stop
-- for a single large PDF, deck, or report, do at most one routing pass across the document plus one focused follow-up read that covers no more than 3 routed pages or sections
-- capture the file's scope, headline facts that are directly exposed, and whether important evidence also lives in charts or tables
-- if the document repeats the same template across many pages or entities, sample only enough pages to describe that repeated structure and preserve routing for later interfaces
-- do not chase every page, every market, every appendix, or every historical chart in this stage
-- leave narrow task-specific extraction to interface workflows
-- once you can state the document scope, the exposed headline metrics, and where deeper chart/table evidence lives, write the summary immediately
-- once the summary file and inventory are written, stop immediately
-- keep bulk PDF/OCR extraction output out of the run log. Save scratch output to temp files and inspect only the routed slices you need for the summary.
-- keep scratch extraction commands single-purpose and non-destructive. Do not use `rm`, wildcard cleanup, `;`, or `&&` chains during summarize.
-- if a shell pattern is blocked, do not retry the same chained command with minor edits. Switch to a simpler local read path and keep moving.
-- if you have already checked whether the summary file exists and it does not, the next step is to write it rather than doing another exploratory read
-- do not precreate `.interf/inventory.json` with `touch`; write the final JSON document directly
-- when updating `.interf/inventory.json`, rewrite the full JSON document in one whole-file write instead of appending or patching partial lines
-- do not use `apply_patch` or line-matched diffs on `.interf/inventory.json`; replace the file in one complete write
-- when you are ready to write, prefer a direct whole-file shell write such as `cat > path <<'EOF' ... EOF` for summary markdown and the inventory artifact
-- whole-file shell writes for stage artifacts are allowed and preferred here; do not stall deciding between patch-based editing and direct writes
-
-## Summary output format
-
-Create one markdown file per source file under `summaries/`.
-Every summary filename must end in `.md`, even when the source file is `.txt`, `.pdf`, or another format.
-If the source file already ends in `.md`, keep a single `.md` suffix instead of appending another one.
-When `.interf/summarize-targets.json` provides `targets[].output`, use that exact path instead of inferring a filename.
-
-Each summary must include JSON frontmatter with:
-- `source`
-- `source_kind`
-- `evidence_tier`
-- `truth_mode`
-- `state`
-- `abstract`
-
-Use JSON frontmatter wrapped in `---` markers. Do not use YAML `key: value` frontmatter.
-
-Example:
-
-```markdown
----
-{
-  "source": "go-to-market-notes.txt",
-  "source_kind": "note",
-  "evidence_tier": "primary",
-  "truth_mode": "proposed",
-  "state": "draft",
-  "abstract": "Short source-grounded description."
-}
----
-```
-
-Each summary must include these sections:
-- `## Overview`
-- `## Key Takeaways`
-
-`## References` is optional.
-
-Keep summaries source-grounded:
-- do not overstate certainty
-- keep titles descriptive and conservative
-- preserve evidence tiers and truth modes
-- keep links sparse and obvious
-- for PDFs, decks, and reports, capture material table/chart/figure evidence when it affects the source's meaning
-- preserve the main headline metrics for the top-level sections or market groups when they are present in extractable text
-- preserve easy headline values from prose or clearly exposed tables when they are central to the source
-- for market reports and dashboards, preserve the main peer groups that are trivial to recover from prose or headline tables, but do not turn summarize into a full market-by-market extraction pass
-- if important evidence appears to live in charts or other visuals, say that clearly in the summary and preserve enough routing detail for a later interface or manual query step
-- do not turn the knowledge-base summarize stage into an exhaustive visual extraction pass across the whole report
-- if exact chart numbers are not directly recoverable from the same page with light local extraction, say so explicitly in the summary instead of flattening the evidence into vague prose
-- when useful, note whether important evidence came from prose, tables, or charts so later interface stages know when raw visual inspection may still be needed
-- distinguish `chart present and relevant` from `exact chart values not yet extracted`
-
-This is a per-file evidence stage only. Cross-file synthesis belongs to `knowledge-base/compile`.
-
-## Inventory output
-
-Write `.interf/inventory.json` so every source file is accounted for.
-
-Minimum shape:
-- prefer the current runtime shape: top-level `entries` plus `total`
-- `total` equal to the actual current source-file count
-- one `entries[]` object per source file
-- each entry should preserve at least `source`, `summary`, and a conservative summarize `status` or `state`
-- per-file routing must let the runtime and validators see which raw file maps to which summary
-
-Do not copy canned totals or filenames into the runtime inventory.
-Do not invent new top-level inventory keys when `entries` already fits the run.
-
-The CLI reconciles `.interf/state.json` and refreshes `.interf/health.json` after stage validation.
-For a one-file summarize run, the finish sequence is strict: write the summary file, rewrite `.interf/inventory.json`, emit `STATUS: batch committed`, emit the standard summarize `DONE:` line using the current run counts, and stop.
-
-## Guardrails
-
-- Do not modify source files.
-- Do not emit `STATUS: batch committed` before files exist on disk.
-- Do not create placeholder JSON files with `touch` before writing the final documents.
-- Do not append a second JSON object to `.interf/inventory.json`. Rewrite the whole file once.
-- Do not use `apply_patch` or line-matched diffs to edit `.interf/inventory.json`.
-- Use a single whole-file write for each required artifact as soon as the summary text is ready.
-- If you check whether a required summary or inventory artifact exists and it is missing, create it next instead of doing another exploratory read.
-- Do not keep mining the source after a usable conservative summary already exists.
-- Do not keep browsing after the required writes are complete.
-- If a required path is missing or unreadable, emit one `BLOCKED:` or `ERROR:` line with the concrete reason and stop.

package/templates/interface/README.md

@@ -1,159 +0,0 @@
-# Interf Interface
-
-Focused local context shells on top of your knowledge base. Any coding agent can navigate them.
-
-## Architecture
-
-```text
-source-folder/
-  interf/
-    {knowledge-base-name}/          knowledge base
-      interfaces/
-        {name}/                     interface
-          interf.json               type: interface, workflow, knowledge_base.path
-          compile-plan.md              interface execution plan
-          AGENTS.md                 bootstrap
-          CLAUDE.md                 Claude Code bootstrap mirror
-          workflow/                 local workflow package
-          home.md                   entry point
-          .gitignore
-          .interf/                  hidden runtime state
-          knowledge/                local entities/claims/indexes
-          briefs/                   hero documents
-          summaries/                periodic summaries
-```
-
-Interfaces are usually created by `interf create interface` from the source folder for a knowledge base. The source folder is the human control plane. The interface is the generated workspace for one job.
-
-Contract model:
-- `type` = engine object kind in config/schema (`interface`)
-- `workflow` = user-facing methodology selection
-- `.interf/stage-contract.json` = generated per-run contract for the active stage
-- executor = the agent/runtime that implements the active stage
-
-## Compile flow
-
-```text
-interf compile:
-  Step 1/3: interface/retrieve   scan all summary frontmatter, prove coverage, compute delta
-  Step 2/3: interface/analyze    batch analysis, extract, refine runtime from evidence
-  Step 3/3: interface/compile    create local context shell, validate
-```
-
-State bridges between steps. If step 2 fails, the next run resumes from step 2.
-
-## Workflows
-
-Shipped built-in interface workflow:
-- `interf`
-
-The selected workflow is written to `interf.json` and can seed starter local `workflow/` docs.
-Use `compile-plan.md` for interface-specific direction such as target entities, years, metrics, chart families, and output focus.
-Create a reusable local workflow only when you want a named method variation you expect to reuse across multiple interfaces.
-
-## Bundled stage skills
-
-| Skill | Step | What |
-|---|---|---|
-| `interface/create` | — | Create interface, draft the initial runtime hypothesis |
-| `interface/retrieve` | 1/3 | Scan the full knowledge-base summary set, persist retrieval proof, compute delta |
-| `interface/analyze` | 2/3 | Batch analysis, subagents, extract entities/claims |
-| `interface/compile` | 3/3 | Build local outputs, validate, clean up |
-
-## interf.json
-
-Minimal. Source of truth for type and knowledge-base reference.
-
-```json
-{
-  "type": "interface",
-  "name": "weekly-briefing",
-  "workflow": "interf",
-  "knowledge_base": {
-    "path": "../.."
-  }
-}
-```
-
-`knowledge_base.path` points to the parent knowledge base. All interface-specific filter criteria, extraction goals, and output specs live in `compile-plan.md`.
-`workflow` records the selected reusable method. Interf generates per-run stage contracts from it for this interface.
-
-If you want to specialize this specific interface, refine `compile-plan.md`.
-If you want a reusable retrieval, ontology, or output method, use a workflow and local `workflow/`.
-If you want a different stage graph, proof model, or required artifacts, that is effectively a new workflow.
-
-`AGENTS.md` is the source of truth. `CLAUDE.md` is a generated mirror so Claude Code picks up the same interface instructions automatically.
-
-`workflow/` is where you can edit interface-local instruction docs:
-- `workflow/README.md`
-- `workflow/create/SKILL.md`
-- `workflow/use/query/SKILL.md`
-- `workflow/compile/stages/retrieve/SKILL.md`
-- `workflow/compile/stages/analyze/SKILL.md`
-- `workflow/compile/stages/compile/SKILL.md`
-
-Simplest pattern:
-- edit `workflow/compile/stages/retrieve/SKILL.md` to change retrieval logic
-- edit `workflow/compile/stages/analyze/SKILL.md` to change ontology/extraction logic
-- edit `workflow/compile/stages/compile/SKILL.md` to change output/navigation logic
-- edit `workflow/use/query/SKILL.md` to change the manual interface query loop
-
-Workflow seeds may already place starter docs in these folders. Treat them as editable local guidance, not as locked system files.
-Use `AGENTS.md` for navigation, command usage, and the manual access checklist. Use `workflow/` for query behavior and stage behavior.
-
-These are the local instruction layer for the interface. Add JSON frontmatter with `mode: extend` or `mode: override` when you want to declare whether a doc should add to or replace the bundled stage instructions for that stage.
-
-Interf still enforces the same coverage proof, artifact schema, and state flow either way.
-If you need a different stage chain, artifact contract, or verifier flow, create a new workflow in the SDK instead of encoding that in local skill docs.
-
-If your coding agent is sandboxed to the current directory tree, launch it from the source folder so the source root, knowledge base, and this interface all stay reachable.
-Use `../../.interf/source-access.json` to verify that raw files are actually reachable before you depend on raw fallback in a manual agent session. `suggested_checks` are canonical absolute file paths so they remain valid from inside the interface folder.
-
-If Obsidian viewer defaults are enabled during `interf init`, newly created interfaces get minimal `.obsidian/graph.json` defaults. They are not registered as standalone workspaces by default; browse them from the parent knowledge-base workspace in Obsidian so knowledge-base summaries and source links remain navigable.
-
-## Runtime files
-
-Interfaces maintain runtime artifacts under `.interf/`:
-- `state.json` — mutable runtime state
-- `health.json` — computed compile status and key metrics
-- `view-spec.json` — presentation contract for cards, graph scope, and navigation
-- `run.json` — current or last deterministic stage run
-- `stage-contract.json` — machine-readable contract for the active stage
-- `run-history.jsonl` — append-only history of completed runs
-- `relevant.json` — selected files for this interface
-- `coverage.json` — retrieval proof for this run
-
-`interf status` for an interface is read-only and deterministic. It checks config, knowledge-base path resolution, broken wikilinks, and retrieval coverage.
-`interf verify interface-plan --json` is the deterministic referee for the scaffold and `compile-plan.md`.
-`interf verify retrieve --json` is the deterministic referee for interface retrieval proof before analyze/build.
-
-See `docs/runtime-contract.md` for the human-readable contract and `src/lib/schema.ts` for the exact runtime schemas.
-
-## compile-plan.md
-
-Generated by `interface/create`. Defines:
-- Stage 1: filter criteria
-- Stage 2: extraction goals and allowed runtime refinements
-- Stage 3: output specs for the local context shell
-
-This is the interface-specific customization layer for the built-in `interf` workflow unless you choose a reusable local workflow instead.
-Compile can refine it when the evidence clearly demands better local structure.
-
-## Key principles
-
-**Local outputs only.** The parent knowledge base is read-only. The interface builds its own `knowledge/` and output folders.
-
-**No auto-cascade.** Knowledge-base compile and interface compile are separate commands.
-
-**Delta compile.** On subsequent runs, only changed files are processed.
-
-**Coverage-gated retrieval.** Retrieval is complete only when the system can prove the full summary set was scanned at the routing layer, candidate abstracts were reviewed, and selected plus rejected sets were persisted.
-
-**Local context shell.** The interface is not just a report folder. It should become the easiest place for an agent to enter, navigate, and understand the relevant slice of the knowledge base.
-
-## Reset
-
-```text
-interf reset compile remove knowledge/ + briefs/, keep summaries/ + config
-interf reset all     remove all generated content, preserve config files
-```

package/templates/interface/interfaces.md

@@ -1,102 +0,0 @@
-# Interface Patterns
-
-Interf currently ships one built-in interface workflow: `interf`.
-That workflow always runs retrieve -> analyze -> compile.
-
-What changes from interface to interface is the use case, the `compile-plan.md` customization, and any optional local workflow extension docs.
-
-Use the patterns below as planning lenses you can encode in `compile-plan.md` or a reusable local interface workflow. They are not built-in workflow ids.
-
-Benchmark queries exist today as validation prompts and expected behaviors. The automated benchmark runner and score logging loop are implemented separately from this shipped template reference.
-
----
-
-## Current-State Briefing Lens
-
-Current-state briefing. Best when you want the latest truth, recent changes, and immediate next steps.
-
-**Questions this interface answers:**
-- What is true right now?
-- What changed recently?
-- What should I focus on next?
-- Which decisions or risks are active?
-
-**Filter:** categories include current-state docs, changelogs, plans, updates, decisions
-
-**Outputs:**
-- Current-State.md — current truth with citations
-- Changes.md — recent changes and trend lines
-- Next-Steps.md — action-oriented follow-through
-
-**Summaries:** weekly, monthly, or milestone-based
-
-**Benchmark queries:**
-- "What is true right now?" — should prefer current, confirmed signals over stale material
-- "What changed recently?" — should compare recent vs prior, not show random old notes
-- "What should happen next?" — should surface evidence-linked actions, not generic advice
-
----
-
-## Research Synthesis Lens
-
-Research synthesis. Best when you want themes, contradictions, evidence strength, and open questions from a dense knowledge base.
-
-**Questions this interface answers:**
-- What are the dominant themes?
-- Which claims are well-supported?
-- Where do sources disagree?
-- What questions still need more evidence?
-
-**Filter:** categories include primary sources, papers, notes, experiments, datasets, repos
-
-**Outputs:**
-- Themes.md — recurring themes with evidence
-- Contradictions.md — disagreements, caveats, counterevidence
-- Open-Questions.md — unresolved questions and next reads
-
-**Summaries:** by topic cluster or period
-
-**Benchmark queries:**
-- "What are the strongest themes?" — should show themes with citations, not loose impressions
-- "Where do sources disagree?" — should show both sides and the evidence basis
-- "What should I read next?" — should turn gaps into concrete next-source suggestions
-
----
-
-## Gap Review Lens
-
-Audit and gap-finding. Best when you want to improve knowledge-base quality, spot stale areas, and surface missing or contradictory evidence.
-
-**Questions this interface answers:**
-- What is missing or weakly covered?
-- Which facts or claims look inconsistent?
-- Which outputs need verification or refresh?
-- What should be added to the knowledge base next?
-
-**Filter:** categories include canonical records, requirements, policies, status docs, recent changes
-
-**Outputs:**
-- Gaps.md — missing areas and thin coverage
-- Contradictions.md — inconsistent facts or claims
-- Follow-Ups.md — concrete verification or ingestion work
-
-**Benchmark queries:**
-- "What is missing?" — should identify concrete gaps, not generic advice
-- "What looks inconsistent?" — should cite the conflicting evidence explicitly
-- "What should we verify next?" — should turn issues into concrete follow-up work
-
----
-
-## Self-improving Loop
-
-Every interface can carry benchmark queries. The intended validation cycle is:
-
-1. Build the interface from its config and current compile plan
-2. Run benchmark queries against the compiled interface workspace
-3. Score: did each query return expected behavior?
-4. If score is below threshold:
-   - Analyze failures
-   - Adjust the interface plan and ontology in `compile-plan.md`
-   - Re-compile
-   - Re-benchmark
-5. Log scores per model per interface for comparison

package/templates/knowledge-base/README.md

@@ -1,137 +0,0 @@
-# Interf Knowledge Base
-
-Your local knowledge base for agents. Attach to any folder, then let Interf compile source files into summaries plus a cross-file knowledge layer.
-
-## Architecture
-
-```text
-source-folder/                  user's files (untouched)
-└── interf/
-    └── {knowledge-base-name}/  knowledge base
-        ├── interf.json         type: knowledge-base, workflow, name, source.path
-        ├── AGENTS.md           bootstrap
-        ├── CLAUDE.md           Claude Code bootstrap mirror
-        ├── workflow/           local workflow package
-        ├── home.md             entry point
-        ├── .interfignore       source exclusion patterns
-        ├── .gitignore
-        ├── .interf/            hidden runtime state
-        │   ├── state.json
-        │   ├── health.json
-        │   ├── source-access.json
-        │   └── view-spec.json
-        ├── summaries/          per-file evidence objects
-        ├── knowledge/
-        │   ├── entities/
-        │   ├── claims/
-        │   └── indexes/
-        └── interfaces/
-            └── {name}/         task-specific interfaces for specific jobs
-```
-
-Knowledge bases are created by `interf create knowledge-base` from the source folder. The source folder is the human control plane. The knowledge base is the generated workspace. One source folder can host multiple named knowledge bases under `interf/` when you want to compare workflows over the same folder.
-
-Contract model:
-- `type` = engine object kind in config/schema (`knowledge-base`)
-- `workflow` = user-facing methodology selection
-- `.interf/stage-contract.json` = generated per-run contract for the active stage
-- executor = the agent/runtime that implements the active stage
-
-## Processing flow
-
-```text
-cd source-folder
-interf create knowledge-base   → creates ./interf/<knowledge-base-name>/
-interf compile:
-  Step 1/2: summarize source files into evidence objects → summaries/
-  Step 2/2: compile cross-file knowledge + retrieval     → knowledge/ + home.md
-```
-
-## Workflows
-
-Shipped knowledge-base workflows:
-- `interf`
-- `karpathy`
-
-Create new reusable workflows from the wizard when you want a named local variation.
-
-The selected workflow is written to `interf.json` and can seed starter local `workflow/` docs.
-
-## Bundled stage skills
-
-| Skill | Step | What |
-|---|---|---|
-| `knowledge-base/summarize` | 1/2 | Generate source-grounded evidence objects for unprocessed source files |
-| `knowledge-base/compile` | 2/2 | Build the cross-file knowledge layer and retrieval structures |
-
-## interf.json
-
-Minimal config. Points to the source folder:
-
-```json
-{
-  "type": "knowledge-base",
-  "name": "my-notes",
-  "workflow": "interf",
-  "source": {
-    "path": "../.."
-  }
-}
-```
-
-`workflow` records the selected methodology. Interf generates per-run stage contracts from it for this knowledge base.
-
-If you want different stage behavior or domain bias, use a workflow and local `workflow/`.
-If you want a different stage graph, proof model, or required artifacts, that is effectively a new workflow.
-
-`AGENTS.md` is the source of truth. `CLAUDE.md` is a generated mirror so Claude Code picks up the same knowledge-base instructions automatically.
-
-`workflow/` is where you can edit knowledge-base-local instruction docs:
-- `workflow/README.md`
-- `workflow/create/SKILL.md`
-- `workflow/use/query/SKILL.md`
-- `workflow/compile/stages/summarize/SKILL.md`
-- `workflow/compile/stages/compile/SKILL.md`
-
-Simplest pattern:
-- edit `workflow/compile/stages/summarize/SKILL.md` to change summarize logic
-- edit `workflow/compile/stages/compile/SKILL.md` to change knowledge-base compile logic
-- edit `workflow/use/query/SKILL.md` to change the manual query loop
-
-Workflow seeds may already place starter docs in these folders. Treat them as editable local guidance, not as locked system files.
-Use `AGENTS.md` for navigation, command usage, and the manual access checklist. Use `workflow/` for query behavior and stage behavior.
-
-These are the local instruction layer for the knowledge base. Add JSON frontmatter with `mode: extend` or `mode: override` when you want to declare whether a doc should add to or replace the bundled stage instructions for that stage.
-
-Interf still enforces the same proof contract, artifact schema, and state flow either way.
-If you need a different stage chain, artifact contract, or verifier flow, create a new workflow in the SDK instead of encoding that in local skill docs.
-
-If your coding agent is sandboxed to the current directory tree, launch it from the source folder so both raw files and this knowledge base stay reachable.
-Use `.interf/source-access.json` to verify that raw files are actually reachable before you depend on raw fallback in a manual agent session. `suggested_checks` are canonical absolute file paths so they still work from nested interface folders.
-
-## Status
-
-Knowledge bases maintain runtime artifacts under `.interf/`:
-- `state.json` — mutable runtime state
-- `health.json` — computed trust surface for summarize/compile status
-- `source-access.json` — raw-file access quick check for manual sessions
-- `run.json` — current or last deterministic stage run
-- `stage-contract.json` — machine-readable contract for the active stage
-- `run-history.jsonl` — append-only history of completed runs
-- `view-spec.json` — viewer-neutral layout contract
-
-`interf status` is read-only and deterministic. It runs source discovery, checks config, summary frontmatter, abstract minimums, and broken wikilinks.
-Use `interf verify summarize --json` after summary generation and `interf verify compile --json` after knowledge-base compilation for explicit pass/fail checks when testing the workflow or driving it from an agent.
-
-See `docs/runtime-contract.md` for the human-readable contract and `src/lib/schema.ts` for the exact runtime schemas.
-
-## Scan accountability
-
-`knowledge-base/compile` writes an inventory of all `summaries/` files before scanning. The scanned count must equal the inventory count. If it does not, the skill stops and reports the gap.
-
-## Reset
-
-```text
-interf reset compile   remove knowledge/, keep summaries/
-interf reset all       remove all generated content, preserve source files
-```

package/templates/knowledge-base/interfignore

@@ -1,19 +0,0 @@
-# Files and directories to exclude from interf source discovery.
-# Same syntax as .gitignore.
-
-# Build artifacts
-dist/
-build/
-out/
-
-# Logs and temp files
-*.log
-*.tmp
-
-# Environment and secrets
-.env
-.env.*
-
-# OS files
-.DS_Store
-Thumbs.db