Hi. Sorry you are stuck and thanks for offering a test file. The code in question is all in the $Rule of the 3 prototypes ‘pAQuestion’, ‘pBClaim’ and ‘pCEvidence’.
Recall that for linked To() (see):
Returns true if the current note links to an item or group of items; this is optionally filtered to only links of type linkType . Put another way, “Does an outbound link exist from the current note to item(s) ?”.
and linkedFrom() (see):
Returns true if the current note is linked to an item ; this is optionally filtered to only links of type linkType . Put another way, Does an inbound link exist to the current note to item ?".
OK, in this code the find() query
$ClaimSupportsID=collect_if(find(linkedTo(that),"Supports"),…
If the text above is runs in the $Rule of Note A then the value of that is $Path(“Note A”).
“Does an outbound link of type “Supports” exist from the current note to ‘Note A’ ?”
The find() tests every note in the document. Let’s assume for a moment, the first note tested is ‘Note B’. At that point the question resolves to:
“Does an outbound link of type “Supports” exist from the ‘Note B’ to ‘Note A’ ?”
I don’t believe that’s really what you want. Let’s try any write your earlier statement in more general logic:
If Note A with $Prototype=“pBClaim” links to Note B (same prototype) with “Supports” linkType, then Note B’s $ClaimSupportsID is filled with Note’s A $ID.
becomes
If a Claim-type note links to another Claim-type note AND that link is of link-type “Supports”, then the $ID of the link’s source note is written to the $ClaimSupportsID of the destination link.
If so, then your linkedTo() test above is the wrong way around. But I’d note at this point you have way to much part-/un-tested code running. At best it is making noise and at worst it is workng against you. So, lest migrate all the rules into ‘Code’-prototyped notes: the prototype ensures the code isn’t mangled and the move stops unwanted code running. To check where rules where, I turned on column view:
Aha! There are at least two notes using locally edited rules that should be inheriting from their prototype. Plus, two notes have a locally set rule (the same one) whose purpose I can’t work out as the is no note named “TbxConfig”.
The ‘List of Questions’ agent has an odd Action. A String-type attributet can only hold zero or a single value so this code is pointless:
$Question=;
$Question=$Name;
As within the same action cycle, $Question is set to no the value and to a value. Here all you need is:
$Question=$Name;
You only need to set a String to empty if you are going concatenate (add to) the existing value with additional data, such as in a list.each(){} loop—which is not the case here.
I note your Oppose/Support attributes are List-type, which allow duplicate entires. As they hold note ID which by nature are unique, why would you want the potential of duplicates. I would make these Set-type. For instance, a given piece of evidence may oppose a claim, using an ‘Opposes’ type-link. Surely it does this one (or zero instance) per evidence/claim pair. does your method allow evidence to both support and oppose a claim; potentially it seems it should but i’m not usre you’ve allowed for this.
But, by trying too many (automation) thinks are once
I suggest starting over, working first and only with one piece of the puzzle at a time, e.g. an evidence note opposes a piece of evidence. Also properly map out the evidence/claim/question paths. Can evidence refute other evidence? Your automation/linking model must allow for any path that occur.
Even with just the two orphan rules running Tinderbox is runnin g at max CPU due to poorly considered use of find(). If all rules are polling all notes all the time, your CPU fans will be on 24/7!
OK, out of time to look at this further. I think the linkTo/Form approach is wrong but I’ve not time to describe other approaches. But, do look at Link Actions. @satikusala has a tutorial using these but i’ll have to ask someone else to find the link.
Here is your file, as discussed above: TBX-file-ed1.tbx (568.8 KB)
I strong suggest you reset all the $ClaimOpposes, EvidenceOpposes, etc., series of attribute values and work up the chain. Do one small_ piece , e.g. ‘evidence opposes’ at a time. Test fix, and move working code yo a new clean TBX. Then start a different small test, in a new test note, fix, migrate code tech. Otherwise, you’ll drown in false stats like the non-inherited rules seen above.