ci: restore the OpenSpec Sync caller on development (#284)

#42 dropped this caller on 2026-08-04, and its reasoning was sound: every run
in the workflow's history was a startup failure reporting `jobs=0` — an
unresolvable reusable workflow, so no log, no step, no verdict, just a
permanently red branch. As that PR put it, a permanently-red workflow is worse
than an absent one, because the next genuine failure lands on an already-red
branch and cannot be told apart from the standing noise.

That argument was right. The condition behind it is gone.

1. THE UNRESOLVABLE REF WAS ALREADY FIXED — one day earlier. 9a695ae landed on
   `main` on 2026-08-03: "fix all 8 shared-workflow callers on main (wrong
   org)". The repair and the removal crossed in mid-air: `main` got the fix,
   `development` got the deletion, and since main sits 345 commits behind
   development the two branches never met. Both changes look correct in
   isolation; together they left the app with a working caller on the branch
   that does not trigger it and no caller on the branch that does.

2. IT HAS NOW BEEN OBSERVED WORKING. Dispatched against main on 2026-08-21,
   this exact caller ran to success and created 12 OpenSpec issues — the first
   non-zero result this workflow has ever produced. The file added here is
   byte-identical to that copy apart from comments.

ON THE EXPIRED TOKEN. #42 and openregister#2111 both attributed the failure to
an expired project-board PAT. That is not what was blocking it here: launchpad
has no PROJECT_TOKEN secret at all, and the run above succeeded regardless.
PROJECT_TOKEN is for the project BOARD; the issues are written with the
workflow's own github.token. The line is kept so board sync starts working by
itself if a token is ever added, and is inert while the secret is absent.

WHY DEVELOPMENT AND NOT ONLY MAIN. The push trigger watches `development`, and
GitHub reads the workflow file from the branch being pushed. With the file only
on main that trigger can never fire — which is why today's sync had to be
kicked by hand with an explicit `--ref main`, and why it covered only main's 16
changes while development's 28 stayed unsynced.

Related: ConductionNL/.github#529 fixed a separate defect in the shared
workflow that was killing sync runs fleet-wide — a hardcoded label description
of 153 characters against GitHub's 100-character limit, which failed the whole
run rather than just that label.

Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>

Author: rubenvdlinde

.github/workflows/openspec-sync.yml

@@ -0,0 +1,51 @@
+name: OpenSpec Sync
+
+# RESTORED, on evidence that the condition which justified dropping it is gone.
+#
+# This caller was removed from `development` in #42 on 2026-08-04 for a good
+# reason: every run in its history was a startup failure reporting `jobs=0`.
+# That is the signature of a reusable workflow that never resolved — no log, no
+# step, no verdict, just a permanently red branch. As #42 put it, a
+# permanently-red workflow is worse than an absent one, because the next
+# genuine failure lands on an already-red branch and cannot be told apart from
+# the standing noise. That argument was correct.
+#
+# What has changed since:
+#
+#   1. The unresolvable ref was FIXED — on `main`, by 9a695ae on 2026-08-03
+#      ("fix all 8 shared-workflow callers on main (wrong org)"), one day
+#      BEFORE #42 dropped this file from development. The fix and the removal
+#      crossed: `main` got the repair, `development` got the deletion, and
+#      because main is 345 commits behind development the two never met.
+#
+#   2. It has now been observed working. Dispatched against main on
+#      2026-08-21, this exact caller ran to success and created 12 OpenSpec
+#      issues — the first non-zero result this workflow has ever produced.
+#
+# On the PROJECT_TOKEN: #42 and openregister#2111 both attributed the failure
+# to an expired project-board PAT. That is not what blocks it here — launchpad
+# has no PROJECT_TOKEN secret at all, and the 2026-08-21 run succeeded anyway.
+# The token is for the project BOARD; the issues themselves are written with
+# the workflow's own github.token. The line below is kept so the board sync
+# starts working by itself if a token is ever added, and is harmless while the
+# secret is absent.
+#
+# Why it belongs on `development` and not only on `main`: the push trigger
+# below watches `development`, and GitHub reads the workflow file from the
+# branch being pushed. With the file only on main, that trigger could never
+# fire — which is why the sync had to be kicked by hand and why only main's 16
+# changes were covered while development's 28 went unsynced.
+
+on:
+  push:
+    branches: [development]
+    paths: ['openspec/**']
+  workflow_dispatch:
+
+jobs:
+  sync:
+    uses: ConductionNL/.github/.github/workflows/openspec-sync.yml@main
+    with:
+      app-name: launchpad
+    secrets:
+      PROJECT_TOKEN: ${{ secrets.PROJECT_TOKEN }}