Справи на диску: корені, паспорт, масове заведення

Довідник до першої сесії (скіл start-research): як завести теки зі сканами, що лежать поза простором, так, щоб реєстр їх побачив і не переплутав.

---

Дві теки на диску: як саме

Найчастіший вхід — не одна справа, а контейнер: «D:/Архів/Метрики» і «D:/Архів/Сповідки», у кожному десятки тек.

1. Оголосити обидва контейнери коренями: nysh roots add D:/Архів/Метрики і nysh roots add D:/Архів/Сповідки. Файли лишаються там, де лежать.
2. nysh cases build — і частина тек дістає ключ сама. Заміряно на живому просторі, що саме його дає:

тека на зовнішньому корені	ключ
…/dahmo_315/spr-103 — в шляху є <архів>_<фонд>	✅ сам
…/сканы-2024/ з _source.json, у якому шифра	✅ сам
…/spr-102 — номер є, архіву в шляху немає	🔴 невидима
…/Книга без імені	🔴 невидима

🔴 «Невидима» тут означає зовсім: ні в справах, ні в unfiled. Тобто імена тек, за якими не видно архіву й фонду, лікуються тільки заведенням. 3. Завести решту: nysh case <тека> --shifra "ДАХмО 315-1-8433" (корінь уже оголошено, --adopt більше не потрібен) — або покласти в теку паспорт _source.json (див. нижче). Коли тек багато, розмножити це можна лише таблицею, яку затвердила людина, — розділ «Масове заведення». 4. nysh cases build ще раз і звірити перелік із кроку 7.

⚠ Обхід іде на чотири рівні вглиб від кореня. Справи, закопані глибше, невидимі — і виглядає це точно як «їх немає». Теки, чиє ім'я починається з _, пропускаються навмисно.

⚠ Один PDF на всю справу — теж справа: рахуються сторінки, а не файли.

---

Паспорт справи: _source.json

Опис живе в теці, а не в окремій базі: тека переїжджає між дисками й потрапляє до колег — опис має їхати з нею. nysh case пише цей файл сам, але його можна покласти й руками або скриптом: бібліотека читає обидва шляхи однаково.

{
  "shifra": "ДАХмО 315-1-105",
  "opis": "1",
  "title": "Метрична книга Покровської церкви",
  "dates": "1847-1852",
  "place": "с. Пилипи, Летичівський пов.",
  "record_type": "метрична",
  "note": "знято в читальному залі"
}

поле	що дає	синоніми, які теж читаються
shifra	🔴 ключ справи — без нього тека невидима	delo: «Ф. 211 Оп. 3 Д. 140»
opis	опис; у частині фондів входить у ключ	inv, opys
title	назва в переліках	—
dates	роки; розбирає й «21.09.1845–1850»	years, пара year_from/year_to, year
place	село й повіт	covers
record_type	тип книги	doc_type

Перевірено на живому просторі: паспорт вище дав у реєстрі шифру, назву, 1847–1852, тип і місце — без жодної команди заведення, самим nysh cases build.

⚠ meta.json читається так само — це друга конвенція, яку пишуть завантажувачі архівів. 🔴 Своє не затирається: nysh case доповнює наявний паспорт (провенанс завантажувача лишається) і ставить слід edited_by_hand.

⚠ Опис фонду сюди не переписують: nysh archive DAHMO 315 каже, чи входить опис у ключ саме в цьому фонді. Питати це треба ДО того, як складати шифру.

Масове заведення: коли можна, а коли ні

Команди «завести все» в пакеті немає, і це навмисно: правдоподібна шифра означає чужий декод під правильним шифром, з якого потім цитують знахідки. Тож масове заведення робиться так:

1. Агент складає таблицю «тека → шифра» — з опису архіву, з імен тек, із титулок, які вже читали. Він її пропонує, а не застосовує.
2. 🛑 Людина затверджує або править. Перед циклом звірити 2–3 рядки з титулкою на скані: помилка тут тиха й виявиться через тиждень чужими сторінками у своїй справі.
3. Аж тоді — цикл по затвердженій таблиці:

while IFS=$'\t' read -r dir shifra; do
  nysh case "D:/Архів/Метрики/$dir" --shifra "$shifra"
done < cases.tsv
nysh cases build

Import-Csv cases.tsv -Delimiter "`t" | ForEach-Object {
  nysh case "D:/Архів/Метрики/$($_.dir)" --shifra $_.shifra
}
nysh cases build

Те саме дає запис паспортів скриптом — команда nysh case і файл _source.json роблять однакову роботу, тож обирай те, що зручніше складати.

Приймач той самий, що в кроці 7: перелік nysh look порівняний із nysh cases list, різниця названа.