Power Capabilities و Wake-on-LAN

1. ارسال فرمان، اثبات تغییر Power State نیست

در کنترل برق node سه اتفاق را نباید یکی فرض کنی: درخواست ثبت می‌شود، شاید delivery انجام شود، و بعد باید state واقعی مشاهده شود. SetSuspendState یا ارسال Magic Packet فقط یک action mechanism است. اگر telemetry مستقل برنگردد، وضعیت باید UNKNOWN یا یکی از stateهای محدود دیگر بماند؛ «command success» به‌تنهایی READY نیست.

2. مرز مالکیت LOC-015

این درس فقط Node Power Capability & Wake Verification Matrix v1 را مالک است: capability → authorization/privilege → bounded request → delivery evidence → observed liveness → application readiness. Control Grant در LOC-013، Resource Envelope در LOC-014 و Desired State reconciliation در LOC-016 قرار دارند. این درس outcome آن‌ها را بازتعریف نمی‌کند.

3. Capability را قبل از Request ثبت کن

برای هر node، power_capability_version باید به evidence مشخصی متصل باشد. برای wake حداقل nic_magic_packet_capability و wake_enabled را جدا نگه دار. وجود MAC address کافی نیست؛ adapter ممکن است Magic Packet را پشتیبانی نکند یا feature غیرفعال باشد. capability یک پیش‌شرط است، نه proof of delivery.

4. Power Stateها برابر نیستند

Sleep، hibernate، shutdown و hybrid shutdown رفتار یکسانی برای wake ندارند. مستندات Windows نشان می‌دهد پشتیبانی WoL به power state وابسته است و Fast Startup/S5 را نمی‌توان مثل S3 یا hibernate فرض کرد. بنابراین observed_power_state باید بخشی از تصمیم باشد و policy نباید همه حالت‌های «خاموش» را در یک boolean فشرده کند.

5. Privilege و Grant دو لایه جدا هستند

برای suspend/hibernate در Windows، caller به SE_SHUTDOWN_NAME نیاز دارد. در MAKNOW نیز grant پروژه باید جداگانه معتبر باشد. داشتن grant بدون OS privilege اجرای request را ثابت نمی‌کند؛ داشتن privilege هم authorization پروژه را ایجاد نمی‌کند. برای actionهای power هر دو لایه باید auditable باشند.

6. Magic Packet فقط یک Delivery Attempt است

Magic Packet معمولاً الگوی wake را با تکرار MAC هدف حمل می‌کند، اما ساختن packet به معنی رسیدن packet به NIC نیست. target_mac، network_path، relay/broadcast mechanism و delivery_evidence باید جدا ثبت شوند. اگر path نامعلوم است، نهایتاً یک attempt محدود ثبت می‌شود و outcome تا مشاهده مستقل UNKNOWN می‌ماند.

7. Wake Enabled را از Wake Capable جدا کن

ممکن است adapter از Wake-on-Magic-Packet پشتیبانی کند اما setting فعلی غیرفعال باشد. پس nic_magic_packet_capability=SUPPORTED و wake_enabled=FALSE یک contradiction نیست؛ یک حالت واقعی است که dispatch را باید BLOCKED کند. capability تاریخی یا inventory قدیمی را به effective enablement تبدیل نکن.

8. Request Issued و Delivery Evidence را جدا نگه دار

request_issued=true فقط می‌گوید coordinator تلاش را آغاز کرده است. برای local suspend ممکن است API request پذیرفته شود؛ برای remote wake ممکن است packet به relay سپرده شود. هیچ‌کدام state نهایی node را ثابت نمی‌کنند. delivery_evidence می‌تواند SENT، UNKNOWN یا FAILED باشد و همچنان به observation بعدی نیاز دارد.

9. Heartbeat یعنی Awake، نه لزوماً Ready

اگر heartbeat identity-bound از همان node برگشت، می‌توان liveness را تقویت کرد؛ اما application ممکن است هنوز NOT_SERVING باشد. در این حالت heartbeat_after_wake=true و health_after_wake=NOT_SERVING باید به NOT_READY برسد، نه READY. readiness فقط وقتی بسته می‌شود که health/readiness evidence هم معتبر باشد.

10. Timeout و Retry باید محدود باشند

Wake loop نباید بی‌نهایت Magic Packet بفرستد. timeout، retry_state و manual recovery باید finite باشند. وقتی path نامعلوم است یا delivery اثبات نشده، retry فقط در budget از پیش‌تعریف‌شده مجاز است؛ بعد از پایان budget، state به DEGRADED/BLOCKED یا recovery دستی می‌رود.

11. Shutdown و Sleep نیز Evidence-confirmed هستند

برای shutdown یا suspend هم request success را با state transition یکی نکن. اگر privilege یا grant معتبر نیست، DENIED بده. اگر request صادر شد ولی observation بعدی نتوانست state را اثبات کند، UNKNOWN نگه دار. این قرارداد دوطرفه است: هم wake و هم power-down به confirmation مستقل نیاز دارند.

12. Matrix باید Reason و Recovery را نگه دارد

هر row باید final_state و reason داشته باشد و اگر بسته نشد، manual_recovery یا recheck trigger را مشخص کند. مثال: «WoL capability unsupported؛ dispatch انجام نشود» یا «path unknown؛ relay/path evidence را refresh کن». بدون reason، audit بعدی نمی‌فهمد چرا automation متوقف شده است.

13. Worked Example: N-31 روی LAN محلی

N-31 در S3 است، grant معتبر است، adapter Magic Packet را پشتیبانی می‌کند، wake enabled است و path محلی reachable است. packet ارسال می‌شود؛ چند ثانیه بعد heartbeat با identity همان node برمی‌گردد و health endpoint SERVING است. فقط در این نقطه matrix می‌تواند READY ثبت کند. packet-send به‌تنهایی چنین حقی نداشت.

14. Failure Probeهای قطعی

چهار mutation را اجرا کن: capability Magic Packet را حذف کن ولی MAC و grant را معتبر نگه دار؛ path را UNKNOWN کن؛ heartbeat را برگردان ولی health را NOT_SERVING نگه دار؛ و برای shutdown privilege را حذف کن. نتیجه باید به‌ترتیب dispatch block، outcome unknown، NOT_READY و DENIED باشد؛ هیچ shortcut optimistic مجاز نیست.

15. Transfer: Remote Site با Trusted Relay

همان workflow را به سایتی منتقل کن که broadcast مستقیم ممکن نیست و relay مورداعتماد packet را محلی emit می‌کند. capability و grant unchanged می‌مانند، اما network_path، delivery evidence، timeout و recovery دوباره محاسبه می‌شوند. baseline local-LAN decision را کپی نکن؛ READY فقط پس از heartbeat و health identity-bound در سایت remote مجاز است.