תהליכי אישור
לאישור יש ערך רק אם הדבר שאושר הוא הדבר שיוצא לפרסום.
זה מתאר עיצוב, לא שירות פעיל
אף מחבר לא מאומת בסביבת הייצור, כך שדבר בדף הזה עדיין לא מתפרסם בשום מקום. איפה שחלק מתהליך העבודה נבנה, זה כתוב. איפה שלא, זה כתוב גם כן.
הבעיה
אישורים בדרך כלל חיים מחוץ לכלי שמפרסם. צילום מסך נשלח ללקוח, הלקוח עונה כן, ואז הטקסט משתנה. האישור מתייחס עכשיו לטיוטה שאף אחד כבר לא מחזיק, והכלי לא יודע על כך, אז הוא מפרסם את מה שניתן לו לאחרונה.
איך המוצר מתוכנן
- אישור מצורף בדיוק לתוכן שנבדק. עריכת טיוטה מאושרת מבטלת את האישור ואומרת איזה שדה השתנה, במקום להעביר בשקט את ההחלטה הישנה הלאה.
- בודק יכול לאשר, לבקש שינויים או לדחות, ותגובה נדרשת עבור כל דבר שאינו אישור, כך שהכותב לעולם לא נשאר מנחש מה לתקן.
- הכלל חי בשכבת האפליקציה המשותפת, כך שאפליקציית האינטרנט, ה-REST API, שרת ה-MCP, שורת הפקודה והוובהוקים כולם מצייתים לו. לאף משטח אין קיצור דרך סביב הבדיקה.
מה באמת נבנה
מצבי האישור, משטח הבדיקה, כללי האישור מחדש ואירועי הביקורת שמאחוריהם נבנו. מה שלא נבנה הוא הצעד האחרון, כי אף מחבר לא עבר את הגדרת המוכנות שלו, כך שלפוסט מאושר עדיין אין לאן ללכת.
מצא משהו לא בסדר בעמוד הזה
Contact channels will be published here before general availability. No legal or support inbox is operating during this preview.