The second issue causes the error #1054: Unknown column 'epochModified' in 'order clause' (note no ft_doc) which isn't exactly the same as the first issue.

I think this is a couple of different issues:

When you use the "Query" field to activate Ferret fulltext search, a "Relevance" score is computed internally. Roughly, today: documents are more relevant if your terms appear in the title than if they appear only in other fields; and stemmed terms are more relevant if the exact term you searched for appears in the raw document than if the stemmed version appears in the normalized version of the document.

PHI379 describes a weird "Copied Lines" signal which can at least be triaged.

this is a very good task :)

haha

I suppose welding does normally take a long time.

Testing any of this is also a pain right now, so before any of that happens I'm going to write bin/harbormaster build --log output.txt or bin/harbormaster write-a-log or something. This overlaps the actual API-writing request in T9124, but that has more complicated concerns (like UTF8 issues, writing to a closed log, etc).

maybe a "grep" would be nice

I'm planning to tackle the build log stuff first since it's the most clear-cut, all fairly close together, and also roughly the most dumb.

The build itself can do this over Conduit. Although it's possible we'll support things like this some day, I think this is currently too niche and disconnected from other application behavior to pursue in the upstream.

See PHI385. I think I stabilized the dashboard arrangement issues in D19123, but the arrange workflows are still in somewhat rough shape.

That is, we mutated the object outside of the Editor, then relied on the Editor to save the mutation.

One overarching issue here is that facts don't have a clear permissions model. It's bad if anyone can go look up the burndown chart for #critical-security-issues and then correlate that chart against tasks showing up in #weird-things-that-happen-when-you-hold-down-the-letter-a or whatever and get a hint about a security concern. In the general case, charts like "Salary by Employee", "Acuisitions Affecting our Stock Price", etc., are also potentially problematic.

• Fact cursors are currently per-object. I think they should likely be per <object, engine> pair so that subsets can be rebuilt more quickly for testing/development and the failure of one engine will not stop all other engines from processing data. On the other hand, fact processing is currently pretty fast and I don't expect to write a ton of engines so I'm not sure how critical this really is. Engines likely don't care how cursors work unless they depend on facts extracted by other engines and need to guarantee they execute later.
• FactEngine->getFactSpecs() isn't really authoritative -- it takes a fact definition externally. I think this should become the authoritative generator. That is, this piece of code needs to go sooner rather than later:

D19111 doesn't fix this in the general case, but should produce the desired behavior for most inputs such that the input is in the form [x](y) and y is the URI of a Wikipedia article.

The intent isn't unambiguous in the general case, consider: Blah blah (see also [x](y)).

The non-bold ones also open in a new tab.

Oh! Yes. Sort of.