// سطح: vasic-util-secondary · سفارش 26

task_bridge scaffoldاجازه‌نامه: UNVERIFIED

GoSQLite (workable-items SSoT)raksul/go-clickup (MIT dependency)HMAC-SHA256 webhook verificationcron + webhookspkg/config runtime injection boundary

منبع

task_bridge — three-way sync (P1 scaffold) Single source of truth last-edit-wins Decoupling: consumer injects creds / IDs → generic engine SQLite SSoT workable-items Tracker docs markdown SSoT ClickUp go-clickup (planned) Daemon webhook HMAC-SHA256 + cron
// معماری

محتوا تخته وظایفتان و منبع حقیقت واحدتان، به‌طور بی‌نقص و دوسویه همگام‌سازی‌شده.

task_bridge یک موتور همگام‌سازی عمومی، جداشده و دوسویه وظایف/تخته در Go است. این ابزار منبع حقیقت واحد اقلام قابل‌انجام SQLite یک پروژه را با مستندات پیگیری‌کننده و تخته راه‌دور آن (اولین هدف: کلیک‌آپ؛ جیرا/لینیر در برنامه) با استفاده از منطق قطعی «آخرین ویرایش برنده می‌شود»، اجرای آزمایشی پیش از اعمال و تضمین عدم خرابی داده‌ها همگام‌سازی می‌کند.

زیرماژولی مستقل از پروژه در Go که اقلام قابل‌انجام SQLite (منبع حقیقت واحد) را به‌طور دوسویه با مستندات پیگیری‌کننده و تخته راه‌دور (ابتدا کلیک‌آپ) همگام‌سازی می‌کند. منطق قطعی «آخرین ویرایش برنده می‌شود»، اجرای آزمایشی پیش از اعمال، وب‌هوک‌های تأییدشده با HMAC؛ هرگونه اعتبارنامه و شناسه در زمان اجرا توسط مصرف‌کننده تزریق می‌شود.

هر تیمی سرانجام دو دفتر ثبت کار یکسان را نگه می‌دارد: یکی واقعی — کد، مستندات، پایگاه داده داخلی — و دیگری که مدیران آن را می‌بینند، تخته‌ای مانند کلیک‌آپ. این دو به محض دستکاری هر یک از طرفین از هم فاصله می‌گیرند و تطبیق دستی آن‌ها دقیقاً همان کار خسته‌کننده و مستعد خطاست که هیچ‌کس به‌طور قابل‌اعتماد انجام نمی‌دهد. task_bridge برای از بین بردن این شکاف طراحی شده است؛ به این صورت که هر سه بازنمایی را به‌عنوان یک سیستم واحد در نظر می‌گیرد که باید همگام نگه داشته شوند: منبع حقیقت واحد اقلام قابل‌انجام SQLite یک پروژه، مستندات پیگیری‌کننده و تخته راه‌دور — اولین تخته پشتیبانی‌شده کلیک‌آپ است و جیرا و لینیر به‌عنوان اعضای آینده برنامه‌ریزی شده‌اند. همگام‌سازی قطعی است (آخرین ویرایش برنده می‌شود)، ابتدا به‌صورت آزمایشی اجرا می‌شود و حول یک وعده غیرقابل‌مذاکره مهندسی شده است: هرگز داده‌ها را خراب یا گم نمی‌کند و هرگز به‌طور خاموش یک طرف را کهنه رها نمی‌سازد. در حوزه‌ای که یک همگام‌سازی بی‌دقت می‌تواند یک هفته کار را بازنویسی کند، این رویکرد ایمنی کل ماجراست. از نظر معماری، این یک زیرماژول سخت‌گیرانه است که توسط پروژه‌های دیگر مصرف می‌شود و کاملاً مستقل از پروژه است (بر اساس قرارداد جداسازی قانون اساسی §۱۱٫۴٫۲۸): هیچ مقدار خاص پروژه‌ای را ارسال نمی‌کند و هرگونه اعتبارنامه، شناسه تخته/پوشه، فیلد کلید آیتم و مسیر پایگاه داده در زمان اجرا از طریق pkg/config.Config توسط مصرف‌کننده تزریق می‌شود. این ماژول به‌صورت لایه‌ای تمیز طراحی شده است: یک CLI (reconcile/push/pull/resolve/status/conflicts/init) و یک دیمن در حال اجرا (گیرنده وب‌هوک + تطبیق دوره‌ای)؛ یک کلاینت نازک بر روی raksul/go-clickup با مجوز MIT؛ یک حل‌کننده که آدرس‌های تخته/پوشه را از طریق کاوش‌های زنده API به شناسه تبدیل می‌کند (بدون حدس زدن گرامر URL)؛ یک نگاشت‌گر بین اقلام قابل‌انجام محلی و فیلدهای وظیفه راه‌دور؛ یک موتور همگام‌سازی «آخرین ویرایش برنده می‌شود» با نتایج صریح تعارض؛ و یک گیرنده وب‌هوک که امضای X-Signature با HMAC-SHA256 را تأیید می‌کند. این ابزار در مورد بلوغ خود صادق است: این اسکلت اولیه اولویت اول است — ساختار، رابط‌ها، نقاط ورود و مرز جداسازی در جای خود قرار دارند، اما منطق همگام‌سازی و فراخوانی‌های زنده کلیک‌آپ هنوز پیاده‌سازی نشده‌اند (هر استاب یک خطای صریح «پیاده‌سازی‌نشده» برمی‌گرداند، طبق قانون عدم استفاده از داده‌های جعلی).

تیم‌ها وضعیت «واقعی» کار را در کد/مستندات نگه می‌دارند، در حالی که مدیران در تخته‌ای مانند کلیک‌آپ زندگی می‌کنند — و این دو دائماً از هم فاصله می‌گیرند. task_bridge آن‌ها را به یک سیستم تبدیل می‌کند، به‌طور قطعی و ایمن همگام‌سازی می‌کند تا هیچ‌یک از طرفین کهنه یا نادرست نشود.

محتوا

همگام‌سازی دوسویه بوردها معمولاً یک یکپارچه‌سازی یک‌باره و سخت‌افزاری است که هر تیمی آن را به شکلی ناقص بازسازی می‌کند. task_bridge این مفهوم را به کتابخانه‌ای قابل‌استفادهٔ مجدد و تزریق‌شونده با اعتبارنامه‌ها بازتعریف می‌کند که تضمین‌های سخت‌گیرانهٔ ایمنی داده‌ها در آن تعبیه شده است — اجرای آزمایشی پیش از اعمال، تعیین اولویت ویرایش نهایی به‌صورت قطعی، و تأیید رویدادها با HMAC — تا هر پروژه بتواند با تزریق پیکربندی، به جای نوشتن یک اتصال‌دهندهٔ شکنندهٔ دیگر که به ساختار داخلی‌اش وابسته است، یکپارچه‌سازی قابل‌اعتماد بورد را به کار گیرد.

  • همگام‌سازی سه‌سویه دوسویه: SQLite (منبع واحد حقیقت) ↔ مستندات ردیاب ↔ بورد از راه دور.
  • جداسازی کامل (§۱۱٫۴٫۲۸): بدون مقادیر ثابت پروژه؛ همهٔ موارد در زمان اجرا تزریق می‌شوند.
  • تبدیل زنده API به شناسه به جای تجزیه نحوی شکنندهٔ دستور URL.
  • دریافت وب‌هوک با تأیید امضای HMAC-SHA256 برای رویدادهای زنده.

  • ایمنی داده‌ها در سه منبع: با تعیین اولویت ویرایش نهایی به‌صورت قطعی، اجرای آزمایشی پیش از اعمال، و نتایج صریح در مواجهه با تداخل حل شد.
  • قابلیت استفادهٔ مجدد بدون وابستگی: از طریق مرز تزریق pkg/config (بدون ارسال جزئیات خاص پروژه) حل شد.
  • شناسایی قابل‌اعتماد بورد: با تبدیل آدرس‌های اینترنتی به شناسه‌ها از طریق پروب‌های زنده API حل شد.
  • داربست صادقانه: با بازگرداندن خطاهای صریح «پیاده‌سازی‌نشده» به جای ارائه نسخه‌های جعلی حل شد.

  • Go — موتور، CLI (cmd/task_bridge) و دیمن (cmd/task_bridged).
  • SQLite — منبع واحد حقیقت برای آیتم‌های قابل‌انجام.
  • raksul/go-clickup (MIT) — بسته‌بندی انتقالی برای کلیک‌آپ.
  • HMAC-SHA256 — تأیید امضای وب‌هوک.
  • کرون + وب‌هوک‌ها — تطبیق دیمن + دریافت رویدادهای زنده.
  • pkg/config — مرز تزریق اعتبارنامه/شناسه در زمان اجرا.

صداقت وضعیت: این یک داربست اولویت اول است — منطق همگام‌سازی هنوز پیاده‌سازی نشده است. آن را به‌عنوان محصول نهایی معرفی نکنید.