תהליכי אישור
לאישור יש ערך רק אם הדבר שאושר הוא הדבר שיוצא לפרסום.
זה מתאר עיצוב, לא שירות פעיל
הבעיה
אישורים בדרך כלל חיים מחוץ לכלי שמפרסם. צילום מסך נשלח ללקוח, הלקוח עונה כן, ואז הטקסט משתנה. האישור מתייחס עכשיו לטיוטה שאף אחד כבר לא מחזיק, והכלי לא יודע על כך, אז הוא מפרסם את מה שניתן לו לאחרונה.
איך המוצר מתוכנן
- אישור מצורף בדיוק לתוכן שנבדק. עריכת טיוטה מאושרת מבטלת את האישור ואומרת איזה שדה השתנה, במקום להעביר בשקט את ההחלטה הישנה הלאה.
- בודק יכול לאשר, לבקש שינויים או לדחות, ותגובה נדרשת עבור כל דבר שאינו אישור, כך שהכותב לעולם לא נשאר מנחש מה לתקן.
- הכלל חי בשכבת האפליקציה המשותפת, כך שאפליקציית האינטרנט, ה-REST API, שרת ה-MCP, שורת הפקודה והוובהוקים כולם מצייתים לו. לאף משטח אין קיצור דרך סביב הבדיקה.
מה באמת נבנה
מצבי האישור, משטח הבדיקה, כללי האישור מחדש ואירועי הביקורת שמאחוריהם נבנו. מה שלא נבנה הוא הצעד האחרון, כי אף מחבר לא עבר את הגדרת המוכנות שלו, כך שלפוסט מאושר עדיין אין לאן ללכת.
Questions
Does this workflow run today?
Not end to end. No connector is verified in production, so nothing described on this page publishes anywhere yet. The section on what is actually built says which parts exist.
Will it use unofficial ways to post?
No. Publishing goes only through each platform's official API. There is no browser automation, no scraping and no automated engagement.
מצא משהו לא בסדר בעמוד הזה
Contact channels will be published here before general availability. No legal or support inbox is operating during this preview.