Populated the OpenSpec config.yaml file

openspec/config.yaml

@@ -1,32 +1,42 @@
 schema: spec-driven
 
-# Project context (optional)
-# Add only constraints that should guide OpenSpec artifacts and workflows.
-# Include constraints an agent cannot infer by reading the code.
-# Keep general project documentation and discoverable codebase facts out.
-# Example:
-#   context: |
-#     Designs and tasks must cover Windows, macOS, and Linux
-#     Write all artifacts in Spanish
+context: |
+  Opportunities Extension supports Oracle Fusion workflows in Chromium/Edge and Firefox.
+  Write OpenSpec artifacts and extension-authored UI text in English; preserve service-provided names.
+  Use openspec/specs/ for behavioral contracts, docs/architecture.md for execution and storage
+  boundaries, README.md for setup and usage, and RELEASE_NOTES.md for release history.
+  Preserve both browser targets and the existing extension design system unless the change
+  explicitly proposes a compatibility or presentation change.
+  When a release is requested, include a valid Firefox XPI; XPI packaging is Firefox-only.
+  Keep the README main title as Opportunities Extension and release history in RELEASE_NOTES.md.
+  OpenSpec archival and product release are separate operations.
 
-# Per-artifact rules (optional)
-# Add custom rules for specific artifacts.
-# Example:
-#   rules:
-#     proposal:
-#       - Keep proposals under 500 words
-#       - Always state what is out of scope
-#     tasks:
-#       - Break tasks into chunks of max 2 hours
+rules:
+  proposal:
+    - Identify affected existing capabilities and distinguish observed behavior from proposed changes.
+    - State scope, non-goals and compatibility impact; do not introduce product requirements for tooling-only changes.
+  design:
+    - Reference the relevant architecture contracts instead of duplicating their inventories.
+    - For affected integrations, describe request ordering, credentials, pagination, retries and stale-response handling.
+    - For affected persistence, describe ownership, identity scope, invalidation and migration or rollback needs.
+    - For UI changes, identify shared components and relevant loading, empty, failure and theme behavior.
+  specs:
+    - Describe observable behavior with testable scenarios; keep implementation steps and module wiring in design and tasks.
+    - Use synthetic identifiers and examples; never embed real tokens, cookies or personal contact data.
+  tasks:
+    - Tie each task to a concrete deliverable and include verification proportional to the affected behavior.
+    - For source changes, include relevant synthetic tests, regeneration of affected browser outputs and a build consistency check.
+    - Record installed-browser and live Oracle checks separately from synthetic tests, including checks not performed.
+    - Include version, release notes and Firefox XPI work only when release delivery is part of the requested scope.
 
-# Per-operation guidance (optional)
-# Add advisory guidance for how apply and archive work should be conducted.
-# This is separate from artifact rules above.
-# Example:
-#   operations:
-#     apply:
-#       guidance:
-#         - Keep test summaries concise
-#     archive:
-#       guidance:
-#         - Summarize the archive outcome before finishing
+operations:
+  apply:
+    guidance:
+      - Edit source modules and regenerate distributions through the build script; do not hand-edit generated bundles.
+      - Use synthetic data for automated checks and avoid incidental writes to live Oracle services during validation.
+      - Run focused checks for the change; use node scripts/test.cjs for integration verification of runtime changes and node scripts/build.mjs --check for generated-output consistency.
+      - Report what changed, verification results and material limitations without claiming unperformed browser or live-service validation.
+  archive:
+    guidance:
+      - Check documentation links when moving a change and preserve the distinction between archived evidence and current specifications.
+      - Summarize task completion, specification synchronization and the final archive location; do not treat archival as a product release.