Projekt

Ogólne

Profil

Akcje
Historia

Strona nadrzędna: Zasady Fabryki

Źródło: ZasadyRealizacji\redmine-instrukcja-dla-projektow.md w drzewie FB. Wiki jest kopią do czytania – zmiany nanosimy w pliku źródłowym, nie tutaj.

Ustanowiona 2026-08-23 po pierwszym pełnym przebiegu kanału zadań (Akademia UKSC, projekt laa-2026). Obowiązuje w każdym projekcie FB – komercyjnym i rozwojowym. Uzupełnia most-sesja-redmine.md (zasada kanału) o stronę wykonawczą: jak wystawiać zadania, czym, w jakim formacie i czego nie robić.

Podział serwerów i kanałów

s62 (projekty.fabrykabezpieczenstwa.pl) s87 (r.fabrykabezpieczenstwa.pl)
Rola klienci: projekty aktualne, baza wiedzy baza Fabryki: projekty rozwojowe, zasady biznesowe
Co trafia ProjektyC\Komercyjne\*, domeny PIWJ, oraz wszystkie zadania – także rozwojowe wiki doktryny i zasad: FB_rozwojowe\*, ZasadyRealizacji\*
Stan działa (wiki + zadania) uruchamiany 2026-08-23; projekt zasady-fabryki

Zadania mają jeden kręgosłup – s62 (rozstrzygnięcie 2026-08-23). Powód: relacje między zgłoszeniami (blokady, powiązania) działają wyłącznie w obrębie jednej instancji Redmine, a zależności między rozwojem a robotą u klientów są realne – wydanie metodyki blokuje zadania wdrożeniowe. Projekt organizacyjny dla rozwoju: fb-rozwojowe (https://projekty.fabrykabezpieczenstwa.pl/projects/fb-rozwojowe/).

Docelowo s87 przejmie także klientów; migracja będzie tania, bo zadania generujemy ze stagingu, a źródłem prawdy są harmonogramy w plikach – przeniesienie to ponowny przebieg skryptu z czystym mapowaniem, nie przepisywanie zgłoszeń.

Kanały równoległe, jedno źródło:

  • pliki projektu (Administracja\Harmonogram.md) – źródło prawdy;
  • Redmine – wykonanie, zależności, przypomnienia mailowe;
  • Google Tasks – prywatny widok dnia (tylko zadania własne).

Skrypty

Skrypt Do czego
ProjektyC\Skrypty\Publikuj-Zadania-Redmine.ps1 zadania → zgłoszenia Redmine (create/update + relacje)
ProjektyC\Skrypty\Publikuj-Zadania-GoogleTasks.ps1 te same zadania → Google Tasks (lista „Fabryka")
ProjektyC\FB_rozwojowe\Redmine\Publikuj-PIWJ-Redmine.ps1 strony wiki PIWJ
Akademia_UKSC_2026-07\Redmine\Publikuj-Akademia-Redmine.ps1 strony wiki Akademii

Oba skrypty zadaniowe czytają ten sam staging: ProjektyC\Redmine_STAGING\zadania\RRRR-MM-DD_<projekt>.json. Podfolder wstrzymane\ = pliki zaparkowane (nie publikują się).

Format stagingu

{
  "projekt": "VCN",
  "projekt_redmine": "vcn",
  "tracker": 2,
  "przypisz_do": 7,
  "przypisz_do_mnie": false,
  "do_google": true,
  "zadania": [
    {
      "id": "VCN-3.1",
      "zadanie": "Warsztaty: szacowanie i ocena ryzyka",
      "opis": "treść z linkami [[Strona_Wiki]]",
      "start": "2026-09-01",
      "koniec": "2026-09-30",
      "godziny": 11.0,
      "tracker": 2,
      "przypisz_do": 7,
      "google": true,
      "zaleznosc": ["VCN-2.5", "VCN-2.6"]
    }
  ]
}

Pola opcjonalne działają kaskadowo: ustawienie przy zadaniu ma pierwszeństwo przed ustawieniem przy pliku.

Pole Znaczenie
tracker typ zgłoszenia; domyślnie 2 = Zadanie. 1 = Uwaga ogólna – bez jawnego podania Redmine wybiera pierwszy typ projektu
przypisz_do numer użytkownika Redmine (Greg = 7)
przypisz_do_mnie true → właściciel klucza API (przydatne przy kontach projektowych, np. LAA2026 = #43)
do_google / google co idzie do prywatnej listy zadań; zadania innych osób zostają wyłącznie w Redmine
zaleznosc jedno ID albo lista ID – zakładane jako relacje blocked
godziny estimated_hours; parowanie z rozliczeniem godzin po id

Trzy role, zero dublowania treści (ustalone 2026-08-23)

  • Redmine – miejsce pracy. Tam się wpisuje ustalenia, podpina dokumenty, prowadzi ślad. Treść zadania żyje tutaj.
  • Google Tasks – magazyn listy dnia. Nie zawiera treści; notatka to link do zgłoszenia plus jedna linia opisu. Termin dzienny, bez godziny.
  • Google Calendar – podgląd. Pokazuje zadania z Tasks obok spotkań; to jest widok, na który Greg patrzy rano na iPadzie.

Konsekwencja praktyczna: z kalendarza klikasz zadanie → link → jesteś w zgłoszeniu, gdzie dopisujesz i podpinasz. Lista dnia zostaje listą, praca zostaje w Redmine.

Konwencje treści

  • ID zadania = identyfikator z harmonogramu, prefiks projektu (VCN-3.1, AQU-01, S2-Z1-U1). Trafia do tematu w nawiasie kwadratowym: [VCN-3.1] Nazwa zadania.
  • Jedno zgłoszenie = jeden produkt. Nie „przerób sekwencję", tylko „wypełnij tabelę charakterystyki".
  • Odesłanie do wiki linkiem [[Nazwa_Strony]], nigdy kopia treści.
  • Narzędzie wskazane wprost – jeśli zadanie wykonuje się promptem, link do strony promptu jest w opisie.
  • Opisy z polskimi znakami; skrypt wysyła treść jawnie jako UTF-8 (PowerShell 5.1 potrafi inaczej zrobić mojibake).

Przebieg

cd C:\Users\Greg\FB\ProjektyC\Skrypty
.\Publikuj-Zadania-Redmine.ps1 -DryRun    # kontrola: co powstanie, komu, z jakimi blokadami
.\Publikuj-Zadania-Redmine.ps1            # na żywo (klucz przez Read-Host)
.\Publikuj-Zadania-GoogleTasks.ps1        # zadania własne do listy „Fabryka"

Cały raport wklejasz do czatu – asystent weryfikuje i odhacza manifest. Klucz API nigdy nie trafia do pliku ani do agenta.

Ziarnistość zadań: jedno zadanie = jeden dokument (2026-08-24)

Zadanie obejmujące pakiet („przegląd sześciu polityk") jest wygodne przy zakładaniu i bezużyteczne w pracy: nie da się go powiązać ze stroną wiki, na której leży konkretny dokument, a postęp widać dopiero po zamknięciu całości.

Reguła: jeden dokument do przeglądu albo opracowania = jedno zgłoszenie. W opisie zgłoszenia pierwszy wiersz to link do strony wiki z dokumentem, dalej liczby (wymagania, pozycje otwarte) i pytanie do rozstrzygnięcia.

Skutki, dla których warto tego pilnować:

  • wiązanie dwustronne – zgłoszenie wskazuje stronę wiki, tabela przeglądu statusów wskazuje zgłoszenie; jedno źródło prawdy, dwa widoki,
  • postęp per dokument zamiast per pakiet,
  • oszacowania są uczciwsze – pół godziny na politykę jest sprawdzalne, trzy godziny na pakiet są życzeniem,
  • pakiet nadal widać: jako wspólny termin i sąsiedztwo w tabeli przeglądu.

Konsekwencja dla wiki: każdy dokument roboczy w formacie md, który czeka na przegląd, dostaje własną podstronę. Bez niej zgłoszenie nie ma do czego odesłać, a przegląd wymaga otwierania drzewa plików zamiast czytania w przeglądarce.

Pułapki techniczne (sprawdzone w boju)

Wszystkie z tej samej rodziny: PowerShell i .NET rozumieją to samo pojęcie inaczej.

Pułapka Objaw Rozwiązanie
Get-Content -Raw + ConvertTo-Json rozsypana treść strony wiki (lekcja UOPP_rozdzial1) czytać przez [System.IO.File]::ReadAllText(..., UTF8)
Kodowanie w REST krzaki w polskich znakach treść wysyłać jako bajty UTF-8 + charset=utf-8 w Content-Type
Ścieżki względne w [System.IO.File] „Nie można odnaleźć części ścieżki C:\WINDOWS\…" .NET rozwija je wobec katalogu procesu, nie lokalizacji PowerShella – normalizować do bezwzględnej (Resolve-Path)
Brak tracker_id zgłoszenia jako „Uwaga ogólna" podawać jawnie, domyślnie 2
Wstawianie wierszy w xlsx rozjechane formuły podsumowań po insert_rows przeliczyć zakresy sum i odwołania
Landing pod własną nazwą zakładka „Wiki" projektu otwiera pusty edytor stronę główną projektu publikować pod nazwą Wiki
Zawinięte akapity w źródle zdania łamane co wiersz (Hardbreaks) staging renderować z rozwiniętymi akapitami (jedna linia = jeden akapit); listy, tabele i cytaty bez zmian

Formatowanie stron wiki – kanon

Nie powielamy tego opisu. Konwencja formatowania stron Redmine jest opisana w pamięci projektu PIWJ i obowiązuje wszystkie projekty:

  • ZasadyRealizacji\pamiec-asystenta\projekty\PIWJ\instrukcja.md, sekcja „Narzędzia i formaty";
  • ZasadyRealizacji\pamiec-asystenta\projekty\PIWJ\memory.md, punkt „Redmine wiki table formatting".

Skrót do szybkiego sprawdzenia (źródłem pozostają pliki wyżej): tabele o nierównych szerokościach wyłącznie HTML <table style="width:100%"> z jawnym style na każdej kolumnie (dwie kolumny 30/70, nawigacyjne trzy 20/35/45); w komórkach HTML używać <strong> i <code>, nie składni Markdown; tekst wprowadzający jako zwykły akapit, nie cytat >; strony złożone jako strona nadrzędna plus podstrony z **Strona nadrzędna:** w nagłówku.

Rejestry na wiki: kotwice i odesłania (zasada, 2026-08-24)

Sprawdzone w boju na s62 przy rejestrze decyzji VCN, potwierdzone przez Grega. Dotyczy każdego rejestru pozycji numerowanych: decyzji, ustaleń audytowych, wymagań, pozycji do potwierdzenia.

Zapis obowiązujący

Rejestr to jedna tabela. Identyfikator pozycji stoi w pierwszej kolumnie jako nagłówek <h3> – i to on tworzy kotwicę.

<table style="width:100%">
<tr><th style="width:6%">Nr</th><th style="width:9%">Data</th><th style="width:22%">Czego dotyczy</th><th style="width:57%">Treść</th><th style="width:6%">St.</th></tr>
<tr><td><h3>D24</h3></td><td>2026-08-03</td><td>Temat pozycji</td><td>Pełna treść</td><td>P</td></tr>
</table>

Odesłanie z dowolnego dokumentu: [[Decyzje#D24|D24]], międzyprojektowo [[vcn-robocze:Decyzje#D24|D24]]. Link dowozi do konkretnego wiersza.

Trzy warunki, bez których to nie działa:

  1. Nagłówek zawiera wyłącznie identyfikator (D24, P-FIZ-03), nigdy tytuł opisowy – kotwica powstaje z treści nagłówka, więc każda zmiana brzmienia zerwałaby wszystkie odesłania.
  2. Atrybutu id nie używamy – jest zbędny (identyfikator i tak powstaje z treści) i bywa usuwany przy sanityzacji.
  3. Odwołania w tekście zawsze jako link, nigdy jako goły kod – D24 w treści dokumentu bez linku jest ślepym zaułkiem dla czytającego.

Co nie działa

Zapis Zachowanie
w treści albo w komórce znacznik usuwany przy renderowaniu, odesłanie ląduje na początku strony
kotwica w komórce bez nagłówka brak celu, jak wyżej

Czego już nie budujemy

Warianty „tabela plus pełne wpisy pod spodem" oraz „dwie strony: tabela i rejestr z nagłówkami" są śladem po nieudanych próbach z kotwicami HTML. Mnożą treść albo miejsca do otwierania, a nagłówek w komórce daje jedno i drugie naraz: widok do skanowania i cel odesłania w tym samym wierszu.

Sesja przeglądarki a świeżość strony

Objaw z 2026-08-24: opublikowana strona nie pokazuje treści, mimo że raport publikacji potwierdza zapis, a historia strony ma nową wersję. Przyczyna nie leży po stronie skryptu ani cache przeglądarki – pomaga wylogowanie i ponowne zalogowanie do Redmine. Zanim zaczniemy szukać błędu w treści, sprawdzamy to jako pierwsze.

Projekt roboczy obok klienckiego (wzorzec z 2026-08-23)

Klient nie ogląda wersji roboczych. Dlatego przy projektach, w których publikujemy treść merytoryczną do Redmine, obowiązuje para projektów:

Projekt Widoczność Rola
-robocze wyłącznie FB (prywatny) wersja wstępna: przegląd, poprawki, praca nad treścią
klient treść zatwierdzona, do której klient ma dostęp

Przepływ: staging → projekt roboczy → przegląd Grega → dopiero stamtąd do projektu klienckiego. Publikacja do projektu klienckiego jest osobną decyzją, nie automatem.

Zastosowanie źródłowe: VCN – 14 obszarów SZBI z plików 00_Wprowadzenie.md jako strony wiki; cel dodatkowy: pokazać klientowi, że cały SZBI da się prowadzić na Redmine, a co najmniej na wiki.

Zasady twarde

  1. Ręczna zmiana w Redmine wygrywa tylko wtedy, gdy wróci do źródła. Po ręcznym przypisaniu albo zmianie statusu: albo parkujesz staging w wstrzymane\, albo nanosisz zmianę w pliku. Inaczej kolejny przebieg przywróci stan z pliku.
  2. Mapowania są święte. mapowanie_<projekt>.json i mapowanie_gtasks_<projekt>.json wiążą ID harmonogramu z numerami zgłoszeń. Skasowanie = duplikaty przy następnym przebiegu.
  3. Agent nie ma dostępu sieciowego do Redmine ani Google. Kończy na stagingu; publikuje człowiek.
  4. Tracker podawaj jawnie (lekcja 2026-08-23: 18 zgłoszeń wyszło jako „Uwaga ogólna").
  5. Nie publikuj zadań innych osób do swojej listy zadań – od tego są flagi kanału.

Google Tasks – uwagi

  • Konfiguracja OAuth jednorazowa; poświadczenia w %APPDATA%\FB\gtasks.cred, szyfrowane DPAPI.
  • Ekran zgody typu Internal (Greg jest administratorem Workspace) – bez testowych użytkowników i bez wygasania tokenu.
  • Google Tasks przyjmuje wyłącznie datę terminu, godzinę ignoruje – zadanie ma dzień, spotkania mają godziny.
  • Lista domyślna: Fabryka (parametr -Lista).

Przypomnienia terminów

Redmine ma wbudowane rake redmine:send_reminders days=N – do wpięcia w cron na s62 ([do zrobienia]). To zdejmuje problem braku przypomnień bez dokładania kolejnego narzędzia.

Numery i identyfikatory

Co Wartość
Greg – użytkownik Redmine 7
Konto projektowe Akademii LAA2026 (#43)
Projekt Akademii laa-2026
Uczestnicy Akademii 2026-07 U1 – Cynamon 16, U2 – lukrak, U3 – GB
Identyfikatory projektów klienckich [do uzupełnienia przy pierwszym pushu] – skrypt zapyta i zapamięta

Uaktualnione przez Greg K 16 dni temu · 1 rewizji