A generic job is one wildcard relation per direction even when every table is known; feedback.md is gitignored only once a map exists

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Author: si1verwind17

skills/visualizing-codebases/CHANGES.md

@@ -5,6 +5,7 @@ Bump `RULES_VERSION` in `scripts/vizcode/__init__.py` with each new section; pru
 
 ## Rules 5 — 2026-10-21
 - Job triggers (SKILL.md § Deployables, not folders): a job that triggers a job of its own service is a `batch` relation too, from the calling job's method to the target task method, keyed `task <name>`; turn a `problems` entry that records such a trigger into that relation.
+- Generic jobs (SKILL.md § Matching interactions): a job whose tables come from its inputs is one relation per direction with a wildcard key and the concrete tables in `tables`, also when every caller passes literal tables; merge relations written one per table into that one.
 
 ## Rules 4 — 2026-10-21
 - Route keys (SKILL.md § Stack): a path parameter is written `{name}` whatever the framework writes around it (`{id:int}`, `{id?}`, `{*id}`, `:id(\d+)` → `{id}`), and a route's path already holds the prefix of a mount in its own file that the scanner joined (`composed onto N routes` in `summary.md`): rewrite `request` keys and example keys that spell a route otherwise.

skills/visualizing-codebases/SKILL.md

@@ -373,7 +373,10 @@ schedule and tasks, each Flyte workflow's launch plan schedule and every
 - A generic job whose tables come from inputs (one replication task, many
   tables) is one relation with a wildcard key (`table sales.*`); list in
   `tables` the concrete tables its callers pass in (literal arguments, or
-  variables set right before the call) or that configs name.
+  variables set right before the call) or that configs name. This holds when
+  every table is known: a caller passing three literal tables still gets one
+  read and one write, each with a wildcard key and those three in `tables`,
+  never a relation per table.
 - `data` says which way data moves: `forward` (from → to), `back` (to → from)
   or `both`. Kinds default (db-read `back`, the rest `forward`); a `stream`
   has no default and must be set: a subscription the service opens is `back`.

skills/visualizing-codebases/feedback.md

@@ -56,4 +56,5 @@ Nothing is posted by you: the last step opens GitHub's new-issue form, filled in
    to step 3. Tell the user the form is open, filled in, and that nothing is posted until they press Submit; they
    can still edit it there or close the tab. If no browser opened, give them the link it printed.
 
-`OUT/feedback.md` is a working file, already gitignored.
+`OUT/feedback.md` is a working file, never committed. The `.gitignore` that `assemble.py` writes keeps it out of git;
+before the first `assemble.py` there is none, so do not tell the user git ignores it.

tests/map/test_rules.py

@@ -161,7 +161,8 @@ def test_rules_two_to_five_follow_the_baseline():
     assert parsed[4][1].startswith("Route handlers (SKILL.md step 5)")
     assert parsed[4][2].startswith("Deployables (SKILL.md § Deployables, not folders)")
     assert parsed[4][3].startswith("Queues in a store or a job system")
-    assert len(parsed[5]) == 1 and parsed[5][0].startswith("Job triggers (SKILL.md")
+    assert len(parsed[5]) == 2 and parsed[5][0].startswith("Job triggers (SKILL.md")
+    assert parsed[5][1].startswith("Generic jobs (SKILL.md § Matching interactions)")
 
 
 def test_a_map_at_rules_one_gets_the_queue_recheck(shop_repo):