Warehouse-Prozess-Analyse mit 207 Labels, 47 Prozessen, 8 Szenarien, 13 Triggern. v7.1 fuehrt P0 als formale Phase, phase_protocol-Artefakte, scenario_trace, Hybrid Governance und kompakte Handover-Regeln ein.
Praezise, quellengebundene Analyse des DaRa-Datensatzes fuer manuelle Warehouse-Prozesse mit harter Trennung zwischen:
contracts/: Governance, MRP, PAC, Routing, Artefaktvertraegeknowledge/: fachliche Quelle der Wahrheitscripts/: kanonische Ausfuehrungslogiktemplates/: Berichtsvorlagen fuer Phase 5schemas/: formale Artefakt- und Protokollschemascompat/: Aliaslayer fuer alte Pfadescripts/, nicht Markdown-Code aus
knowledge/processes/*.md.knowledge/ als fachliche Quelle der Wahrheit, wenn Code und Text
konfligieren.P0-P5 und P2b immer fuer genau einen vom Nutzer genannten .subject_idLies in dieser Reihenfolge:
contracts/reading_protocol.mdcontracts/routing_matrix.mdcontracts/artifact_contracts.mdcontracts/response_protocol.mdDanach:
knowledge/scripts/knowledge/processes/phase5_report.md plus genau ein TemplateEine Datei gilt nur als vollstaendig gelesen, wenn sie bis zum Dateiende
eingelesen wurde und vorhandene VERIFICATION_TOKENs extrahiert wurden.
P0: Annotation Bundle und Protokollbildung aus den 12 Roh-CSV-Dateien
mit normalized.duckdb und frame_records.parquet als kanonischer BasisP1: Szenarioerkennung, erzeugt p1_scenario_trace und p1_phase_protocolP2: REFA-/DaRa-Zeitanalyse, erzeugt p2_refa_analysis und
p2_phase_protocolP2b: REFA-Ablaufanalyse (v0.3.0), erzeugt
p2b_refa_ablaufanalyse und p2b_phase_protocolP3: MTM bleibt contract-only und wissensbasiertP4: Process-Validierung, erzeugt Validierungsartefakt und p4_phase_protocolP5: Berichtserstellung, nutzt Protokolle zuerst und Templates genau einmalknowledge/processes/phase1_scenario_recognition.mdknowledge/processes/phase2_refa_analysis.mdknowledge/processes/phase2b_refa_ablaufanalyse.mdknowledge/processes/phase3_mtm_analysis.mdknowledge/processes/phase4_bpmn_validation.mdknowledge/processes/phase5_report.mdknowledge/processes/reference_bpmn_flows.mdknowledge/core/reference_labels.mdknowledge/core/reference_activation_rules.mdknowledge/core/reference_validation_rules.mdknowledge/core/reference_dataset.mdknowledge/core/reference_warehouse.mdknowledge/core/reference_articles.mdknowledge/methods/reference_chunking.mdknowledge/methods/refa_phase2_manual_order_picking.mdtemplates/scenario_report.mdtemplates/phase2_refa_einzelreport.mdtemplates/process_report.mdtemplates/session_comparison_report.mdscripts/common/annotation_bundle.pyscripts/phase1/scenario_recognition.pyscripts/phase2/refa_analysis.pyscripts/phase2b/refa_ablaufanalyse.pyscripts/phase4/process_validation.pyscripts/phase5/render_subject_report.pyscripts/session/render_multi_session_comparison.pyschemas/p0_frame_records.schema.jsonschemas/p0_phase_protocol.schema.jsonschemas/p1_scenario_trace.schema.jsonschemas/p1_phase_protocol.schema.jsonschemas/p2_phase_protocol.schema.jsonschemas/p2_refa_analysis.schema.jsonschemas/p2b_refa_ablaufanalyse.schema.jsonschemas/p2b_phase_protocol.schema.jsonschemas/p3_phase_protocol.schema.jsonschemas/p4_phase_protocol.schema.jsonschemas/p5_report_meta.schema.jsonFuer Folgephasen, Review und LLM-Handover gelten:
phase_protocol-Artefakte zuerstnormalized.duckdb oder frame_records.parquet,
nicht grosses P0-JSONP2 und P2b bleiben template-frei. Eine Anfrage nach probandenweisem
Zeitaufnahme-/REFA-Bericht ist eine P5-Berichtsanfrage mit
templates/phase2_refa_einzelreport.md.
Sessionuebergreifende oder mehrprobandige Sammelreports laufen post-run ueber
scripts/session/render_multi_session_comparison.py und greifen auf bereits
vorliegende Session-Summaries/Protokolle zu.
PAC bleibt vor jeder Fachantwort Pflicht.VERIFICATION_TOKENs werden aus geladenen Referenzen dokumentiert.comparison_core wird pro Phase budgetiert und spaeter fuer
Mehr-Probanden-Vergleiche verwendet.metadata.duckdb ist die kanonische lokale Metadatenbasis fuer
artifact_registry, comparison_cores und eval_runs.