Každodenní použití a příklady zadání

Nejlepší výsledky vznikají, když uživatel popíše požadovaný výsledek v aplikaci, nikoli pouze XML konstrukci. XDS authoring potom propojí přesnou syntaxi se smyslem, vazbami a ověřením.

Univerzální šablona zadání

Cíl: Co má uživatel aplikace vidět nebo umět udělat?
Kontext: Který dokument, formulář, hodnota nebo proces řešíme?
Podklad: Který soubor či anonymizovaný úryvek je relevantní?
Režim: Vysvětlení | read-only review | návrh | oprava | dopadová analýza.
Výstup: Tabulka nálezů | plán | minimální diff | checklist | vysvětlení.
Omezení: Bez zápisu, bez tools, bez Replicatoru; případně povolený scope.
Evidence: Uvést schema/reference/inference a nejvyšší ověření.

Není nutné vyplnit všechna pole formálně. Jejich uvedení ale výrazně omezuje nedorozumění.

Příklady podle situace

Potřebuji pochopit cizí XDS

Popiš tento úryvek pro konzultanta, který nezná XML detaily. Vysvětli účel jednotlivých částí, návaznosti a co může uživatel vidět ve formuláři. Pokud runtime dopad nelze z podkladu dokázat, označ jej jako předpoklad.

Nevím, zda je konstrukce povolená

Použij xds-schema-reader. Ověř v aktuálním schema.mxl, zda je uzel <...> povolen pod <...>, jaké má přímé potomky a které atributy jsou dostupné. Nevysvětluj obchodní význam, pokud jej schema samo nedokládá.

Chci zkontrolovat připravenou změnu

Použij xds-review a proveď pouze read-only revizi změněného úseku. Zkontroluj schema, vazby mezi dotčenými vlastnostmi, riziko změny short, přístupy a možné dopady do formuláře a dat. Výstup dej do tabulky: závažnost, místo, problém, evidence, doporučení, potřebná validace.

Potřebuji navrhnout nové chování

Použij xds-authoring. Cílem je [popis chování]. Nejprve uveď dotčené znalostní skupiny a otevřené otázky. Potom navrhni minimální XDS změnu. Zachovej existující hodnoty short, pokud není doložen důvod je změnit. Nic nespouštěj; přidej plán ověření.

Mám validační chybu

Použij xds-repair. Zde je přesná chybová zpráva a minimální okolí problematického místa. Urči kořenovou příčinu, odliš kaskádované chyby, ukaž nejmenší opravu a napiš, kterou kontrolu zopakovat jako první.

Potřebuji znát dopady

Použij xds-analyze-impact. Pro navrženou změnu popiš dopad do dat, formuláře, práv, lokalizace, integrací, generovaných artefaktů a existujících referencí. U každé oblasti uveď jistotu a doporučený způsob ověření.

Jak pracovat po iteracích

U složitého zadání nepřeskakujte rovnou k velké úpravě.

1. Vymezení: „Shrň cíl, dotčené soubory a nejasnosti.“
2. Evidence: „Ověř pouze syntaxi a dostupnost konstrukcí.“
3. Návrh: „Navrhni minimální variantu a jednu alternativu.“
4. Revize: „Zkontroluj návrh read-only proti vazbám a dopadům.“
5. Provedení: povolte jen konkrétní soubor a konkrétní změnu.
6. Validace: samostatně schvalte kontrolní příkaz.
7. Vyhodnocení: vraťte report a nechte odlišit primární a následné chyby.

Tento postup je použitelný i pro ne-IT pracovníka: u každé etapy stačí potvrdit, zda výsledek odpovídá požadovanému chování.

Co přikládat

Přikládejte nejmenší podklad, který stačí k rozhodnutí:

• relevantní XDS soubor nebo úryvek s rodičovským kontextem;
• přesnou chybovou zprávu;
• stručný popis požadovaného chování;
• u lokálního projektu cestu k souboru;
• případně anonymizovaný příklad vstupu a očekávaného výsledku.

Nepřikládejte celý produkční export, credentials, skutečné osobní údaje ani obsah nesouvisejících klientů. Do XDS nevkládejte XML komentáře jako pracovní poznámky; rozhodnutí a otevřené body patří do doprovodného Markdown logu.

Jak požadovat srozumitelný výstup

Pokud je odpověď příliš technická, napište například:

Přepiš závěr pro analytika bez znalosti XML. Zachovej přesné názvy XDS vlastností v závorkách. U každého doporučení napiš, co se změní pro uživatele aplikace a co ještě musí ověřit technik.

Pro předání technikovi naopak požadujte:

Přidej přesné cesty k souborům, dotčené uzly, minimální diff, zdroj evidence a kontrolní příkazy pouze jako návrh ke schválení.

Doporučený formát revize

Závažnost	Místo	Zjištění	Proč je důležité	Evidence	Další krok
blokující	cesta/uzel	schema nepovoluje konstrukci	validace pravděpodobně selže	živé schema	opravit před další prací
vysoká	cesta/uzel	změna může ovlivnit identitu dat	možné porušení vazeb	reference + impact	odborná revize a test
střední	cesta/uzel	nejasná kombinace vlastností	chování není plně doložené	partial evidence	cílená validace
informace	cesta/uzel	doporučení pro čitelnost	bez známého runtime dopadu	praktický vzor	volitelná úprava

Uzavření úkolu

Před označením práce jako hotové si nechte odpovědět:

• co přesně bylo změněno a co zůstalo beze změny;
• jaké zdroje byly použity;
• která validační úroveň skutečně proběhla;
• jaké mezery zůstávají;
• zda je možné změnu bezpečně vrátit;
• kdo má schválit další mutující krok.